Re: [infinispan-dev] ClockService

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.

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(a)infinispan.org&gt; 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(a)redhat.com&gt; 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(a)jboss.org >> twitter.com/maniksurtani >> >> Platform Architect, JBoss Data Grid >> http://red.ht/data-grid >> >> >> _______________________________________________ >> infinispan-dev mailing list >> infinispan-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/infinispan-dev > > _______________________________________________ > infinispan-dev mailing list > infinispan-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/infinispan-dev -- Manik Surtani manik(a)jboss.org twitter.com/maniksurtani Platform Architect, JBoss Data Grid http://red.ht/data-grid _______________________________________________ infinispan-dev mailing list infinispan-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev