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.
On 30 Jan 2013, at 08:41, Bela Ban <bban@redhat.com> wrote:
>
> On 1/29/13 6:45 PM, Manik Surtani wrote:
>> On 29 Jan 2013, at 17:17, Bela Ban <bban@redhat.com> wrote:
>>
>>> On 1/29/13 5:25 PM, Sanne Grinovero wrote:
>>>> Glad you started work on that :)
>>>>
>>>> Any currentTimeMillis() even today will blow away your cache line and
>>>> probably trigger a context switch.
>>> I understand the context switch (in general, it's not recommended anyway
>>> to invoke a system call in synchronized code), but I fail to see why
>>> this would blow the cache line. Are you referring to the cached Date
>>> value here ?
>> No, if you have a separate maint thread that updates a reusable currentTimeMillis value.
>>
>> Do you use nanoTime() a lot then? Because that too is inefficient (as per the Oracle blog) ...
>
> Define inefficient !
http://bugs.sun.com/view_bug.do?bug_id=6876279
> the latter wins…
> 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
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.
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.
> 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.
- M
>
> --
> Bela Ban, JGroups lead (http://www.jgroups.org)
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
--
Manik Surtani
manik@jboss.org
twitter.com/maniksurtani
Platform Architect, JBoss Data Grid
http://red.ht/data-grid
_______________________________________________
infinispan-dev mailing list
infinispan-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev