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) _______________________________________________ infinispan-dev mailing list [email protected] https://lists.jboss.org/mailman/listinfo/infinispan-dev
