You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@helix.apache.org by "Hudson (JIRA)" <ji...@apache.org> on 2019/04/12 16:47:00 UTC

[jira] [Commented] (HELIX-816) new Date.getTime() can be changed to System.currentTimeMillis()

    [ https://issues.apache.org/jira/browse/HELIX-816?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16816453#comment-16816453 ] 

Hudson commented on HELIX-816:
------------------------------

FAILURE: Integrated in Jenkins build helix #1620 (See [https://builds.apache.org/job/helix/1620/])
HELIX-816 use System.currentTimeMillis() (narendly: rev efef0dbb3e2020546686ca617c03c59330ba9418)
* (edit) helix-core/src/main/java/org/apache/helix/messaging/AsyncCallback.java
* (edit) helix-core/src/main/java/org/apache/helix/messaging/handling/HelixStateTransitionHandler.java


> new Date.getTime() can be changed to System.currentTimeMillis()
> ---------------------------------------------------------------
>
>                 Key: HELIX-816
>                 URL: https://issues.apache.org/jira/browse/HELIX-816
>             Project: Apache Helix
>          Issue Type: Bug
>            Reporter: bd2019us
>            Priority: Major
>              Labels: patch
>         Attachments: 1.patch
>
>          Time Spent: 20m
>  Remaining Estimate: 0h
>
> Hello,
> I found that System.currentTimeMillis() can be used instead of new Date.getTime().
> Since new Date() is a thin wrapper of light method System.currentTimeMillis(). The performance will be greatly damaged if it is invoked too much times.
> According to my local testing at the same environment, System.currentTimeMillis() can achieve a speedup to 5 times (435 ms vs 2073 ms), when these two methods are invoked 5,000,000 times.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)