[infinispan-dev] ClockService

[Mircea Markus]

On 29 Jan 2013, at 16:25, 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.
> 
> Having it as a service we will be able to experiment: the first thing
> I'll do is replace it with a NOOPService and see how much it improves.
That should be the first step IMO. No point in trying to start optimising before we know this is a performance problem :-) 
> 
> Ideally I'd like it to have multiple methods so that different needs
> can hint about a different level of precision, or maybe expect an enum
> as parameter which represents the hint.
> 
> Cheers,
> Sanne
> 
> On 29 January 2013 16:02, Manik Surtani <msurtani at redhat.com> wrote:
>> Thinking about Sanne's idea re: a clock service and not continuously relying on System.cTM, I stumbled upon this:
>> 
>> https://blogs.oracle.com/ksrini/entry/we_take_java_performance_very
>> 
>> The last section re: caching is interesting.
>> 
>> Having all code use a Clock.currentTimeMillis() and having an implementation that kicks off a scheduled task to update a cached value every $frequency millis (by using the System call) is probably the correct way to implement something like this, but this adds complexities/concerns:
>> 
>> * CPU cache line blowing away (see article)
>> * Context switching
>> * Managing an extra service thread
>> * Probably an additional configuration option to configure that thread, its priority and frequency.  If frequency is dropped (e.g., every second) I suppose the perf gains would be huge.
>> 
>> JGroups - does JGroups make many and frequent calls to System.cTM as well?
>> 
>> Cheers
>> Manik
>> --
>> Manik Surtani
>> manik at jboss.org
>> twitter.com/maniksurtani
>> 
>> Platform Architect, JBoss Data Grid
>> http://red.ht/data-grid
>> 
>> 
>> _______________________________________________
>> infinispan-dev mailing list
>> infinispan-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
> 
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev

Cheers,
-- 
Mircea Markus
Infinispan lead (www.infinispan.org)




-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/infinispan-dev/attachments/20130129/99b021a7/attachment.html