[infinispan-dev] Time measurement and expiry

[Manik Surtani]

+1.  Looking forward to your patch.

On 2 Nov 2011, at 15:39, Sanne Grinovero wrote:

> I've experimented with some implementations; since the simplest
> approach just removes and simplifies code while providing a
> significant speedup I'm going to send a pull request for that one: I
> just have to add some additional methods to InternalCacheEntry, and
> get a good improvement in the eviction "scanning".
> 
> Since with 10 million entries it's able to scan/check them all in a
> timewindow close to a single second (~ 1,2 s on my laptop), I'm then
> proposing as well the second change to remove the "precision check" at
> all, which means we don't need any clock and I just need to remove
> some ~40 lines of useless and slow code. It seems we're all agreeing
> that higher precision is pointless, correct? Especially since the
> eviction thread can finish a full scan quicker.
> 
> Cheers,
> Sanne
> 
> On 2 November 2011 14:45, Manik Surtani <manik at jboss.org> wrote:
>> 
>> 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 at jboss.org
>> twitter.com/maniksurtani
>> 
>> Lead, Infinispan
>> http://www.infinispan.org
>> 
>> 
>> 
>> 
>> _______________________________________________
>> infinispan-dev mailing list
>> infinispan-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>> 
> 
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev

--
Manik Surtani
manik at jboss.org
twitter.com/maniksurtani

Lead, Infinispan
http://www.infinispan.org