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 <[email protected]> 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 <[email protected]> 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 >> [email protected] >> twitter.com/maniksurtani >> >> Platform Architect, JBoss Data Grid >> http://red.ht/data-grid >> >> >> _______________________________________________ >> infinispan-dev mailing list >> [email protected] >> https://lists.jboss.org/mailman/listinfo/infinispan-dev > > _______________________________________________ > infinispan-dev mailing list > [email protected] > https://lists.jboss.org/mailman/listinfo/infinispan-dev -- Manik Surtani [email protected] twitter.com/maniksurtani Platform Architect, JBoss Data Grid http://red.ht/data-grid _______________________________________________ infinispan-dev mailing list [email protected] https://lists.jboss.org/mailman/listinfo/infinispan-dev
