[infinispan-dev] ClockService

[Bela Ban]

Seems that the bug you mention below was not deemed critical by 
SUN/Oracle, as it won't get fixed.

Wrt JGroups use, I only call nanoTime() when I need fine grained 
resolution, e.g. in perf tests, or in the following places:
- Timeouts waiting for results from RPCs. Here, we're usually talking 
seconds
- Message bundlers: to measure the elapsed time. Usually done every 30 
ms. This is the most frequent use of the method, but it will disappear 
completely as I intend to remove max_bundling_time when [1] is 
implemented (soon).
- Flow control: compute the block time if we block on credits (infrequent)
- Timer: to compute the next execution time in the DelayQueue. Most 
tasks have intervals between 500ms and a few seconds, so this isn't 
critical either

So for JGroups, message bundling would be the only place where we call 
nanoTime() frequently, but this will go away in 3.3.

Wrt currentTimeMillis(), most usage is in the seconds range (everything 
else was change to nanoTime()), so this isn't critical either.

[1] https://issues.jboss.org/browse/JGRP-1540


On 1/30/13 9:53 AM, Manik Surtani wrote:
>
>> Define inefficient !
> There was once a misconception that nanoTime() was faster (by an order of magnitude) that currentTimeMillis().  And a similar misconception going the other way.  The reality, it would seem, is that they're both *fairly inefficient*, depending on OS architecture.
>
> http://bugs.sun.com/view_bug.do?bug_id=6876279
>
>> I'm sure we're talking about nanosec / microsec
>> ranges here, so 3% faster won't cut it for me. If you contrast that to
>> my current work, where I try to deliver a batch of N messages and
>> therefore can skip N-1 lock acquitions/releases for M protocols, then
>> the latter wins…
> Right, I'm not entirely sure it is a hotspot for optimisation though.  I'm going by some research that Sanne did and I'm doing a bit more homework around that.
>
>> I still think a clock service is interesting, but for different reasons.
>> As Sanne mentioned in Palma, it would be interesting to 'control' time,
>> e.g. deliver 2 messages at the same time, or even go backwards in time.
>> In the case of JGroups, we could use a clock service to screw up message
>> reception (e.g. in testing) and therefore to test the correctness of
>> some protocols.
> Right, but for me that would be an additional benefit and I would de-prioritise if that was all I was getting from it.  If it is even a moderate performance boost though, say over 3% overall for such a small/simple change, then I'd do it.
>
>

-- 
Bela Ban, JGroups lead (http://www.jgroups.org)