[ 
https://issues.apache.org/jira/browse/HADOOP-3524?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12603850#action_12603850
 ] 

Steve Loughran commented on HADOOP-3524:
----------------------------------------

on the same machine, try measuring the cost of System.nanoTime(). it may be 
lower cost.


many years ago I did some experiments with JNI calling the x86 opcode for the 
in-CPU clock; I think it put the round trip time from Java to assembler and 
back at about 600 cycles on a PII system. Not great, but not neglible. It may 
be cheaper than System.currentTimeMillis(), though it may get confused by CPUs 
varying their clock speeds, and virtual machines moving at a very slow clock 
rate compared to wall time -you'd have to test that too.

> JobTracker's processHeartbeat() should not call System.currentTimeMillis() 
> everytime
> ------------------------------------------------------------------------------------
>
>                 Key: HADOOP-3524
>                 URL: https://issues.apache.org/jira/browse/HADOOP-3524
>             Project: Hadoop Core
>          Issue Type: Improvement
>          Components: mapred
>            Reporter: Amar Kamat
>         Attachments: CurrentTimeCost.java
>
>
> Consider the following
> {code:title=JobTracker.java|borderStyle=solid}
> private synchronized boolean processHeartbeat(
>                                                 TaskTrackerStatus 
> trackerStatus, boolean initialContact) {
>     String trackerName = trackerStatus.getTrackerName();
>     trackerStatus.setLastSeen(System.currentTimeMillis());
> {code}
> Here, the call to {{System.currentTimeMillis()}} on every call to 
> {{JobTracker.processHeartbeat()}} might prove costly. While 
> testing/benchmarking HADOOP-2119, we recorded that the JobTracker was able to 
> serve ~130 tasks/sec. So that means we might make ~130 calls to 
> {{System.currentTimeMillis()}} per second. I think in these cases 
> (_last-seen-status_ etc) such a high level of accuracy in terms of timestamp 
> is unnecessary and hence can be avoided.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Reply via email to