Re: [infinispan-dev] Time measurement and expiry

On 30 Oct 2011, at 23:58, Dan Berindei wrote: > Cool link Elias, I read the paper linked in the javadoc and it's very > interesting. > > Netty seems to use scheme 6 (a single array of lists with hashing and > without any overflow). I believe in general our timeouts will be much > longer so I suspect scheme 5 or scheme 7 should perform better for us. > > Scheme 5 should be much better than 6 if most of the timeouts use the > same value, and I believe we fit right in that use case. > On the other hand I think we could save some memory if we implement > scheme 7 by not actually storing the higher level wheels and building > them on the fly by iterating the data container. The downside is that > we'll need periodic sweeps of the data container, but those can be on > a separate thread. -1.  I'd prefer an approach that does not involve any additional management threads. > One scenario that we should keep in mind is the L1 cache, whose > entries I would guess are invalidated much more often than they expire > after their 1 hour lifetime. If the user stores only immortal entries > + L1 entries in the cache we might end up with a ticker task that > never rarely does anything useful so we should minimize its impact. > > It might also be worth it to implement our own list type to make > adding and removing timeouts faster. I see Netty uses > IdentityHashMap-backed sets for the bucket lists, but as Sanne found > out they aren't the fastest thing around. Using a doubly-linked list > and keeping a reference to the Node in the cache entry should make it > much faster. Yes, I think implementing our own is the way forward as well.  No sense in adding dependencies for just a single class, etc. Cheers Manik -- Manik Surtani manik(a)jboss.org twitter.com/maniksurtani Lead, Infinispan http://www.infinispan.org _______________________________________________ infinispan-dev mailing list infinispan-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev