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 <[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
Cheers, -- Mircea Markus Infinispan lead (www.infinispan.org)
_______________________________________________ infinispan-dev mailing list [email protected] https://lists.jboss.org/mailman/listinfo/infinispan-dev
