On Jan 29, 2013, at 6:07 PM, Manik Surtani <[email protected]> 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 <[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 -- Galder Zamarreño [email protected] twitter.com/galderz Project Lead, Escalante http://escalante.io Engineer, Infinispan http://infinispan.org _______________________________________________ infinispan-dev mailing list [email protected] https://lists.jboss.org/mailman/listinfo/infinispan-dev
