[infinispan-dev] ClockService

[Galder Zamarreño]

On Jan 29, 2013, at 6:07 PM, Manik Surtani <msurtani at redhat.com> wrote:

> Interesting; looking at the code a bit more, I don't think this offers any improvements except in the case where expiry is set.  Granted, this is a useful thing to have at that point, but I'm not entirely sure whether it will affect the majority of users.

^ Just remember what I mentioned in a previous email WRT local cache performance. Avoiding size based eviction and giving your entries expiration times is a great way to enhance the improve performance of a local cache while relatively controlling its memory consumption.

> 
> Anyway, to measure any benefit, I'm also going to have to enhance RadarGun to (optionally) set expiry information on data stored.
> 
> - M
> 
> 
> On 29 Jan 2013, at 16:25, Sanne Grinovero <sanne at infinispan.org> 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.
>> 
>> 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
> 
> --
> 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


--
Galder Zamarreño
galder at redhat.com
twitter.com/galderz

Project Lead, Escalante
http://escalante.io

Engineer, Infinispan
http://infinispan.org