You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avalon.apache.org by Alexis Agahi <al...@agahi.com> on 2002/01/07 00:17:09 UTC
excalibur.cache.LRUCachePolicy
Hi,
I've checked the cache implementation from excalibur scratchpad
and notice that LRUCachePolicy use the ListCachePolicy LinkedList
to perform the LRU mecanism.
To have a LRU 'hit' effect, it removes the object from the list
and put it at the top.
What if the list is really huge? I mean, to perform the remove it
has to scan the whole list, since it doesn't have an index (or
I'm wrong)?
I would suggest having another approach using a logical clock
value and 'time' hashmap.
Something like:
When a 'hit' is called, it gets the current object and set its
'value' to the current logical time.
To remove the oldest, it gets the oldest value in the time map.
To be really honest, this approach is not necessarily the best:
the remove case is slower that the linked list one, but the 'hit'
could be faster. Now it depends on the hit/remove ratio. But I
guess in an LRU cache, you should have a maximum of 'hit' call.
Regards
--
mailto:alag@users.sourceforge.net -
http://sourceforge.net/projects/jabaserver
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: excalibur.cache.LRUCachePolicy
Posted by Alexis Agahi <al...@agahi.com>.
Eung-ju Park wrote:
> > To have a LRU 'hit' effect, it removes the object from the list
> > and put it at the top.
> > What if the list is really huge? I mean, to perform the remove it
> It is not a Cache if it is really huge. ;-) Just kidding.
Well I think something greater than 100 elements is enough to get
a real speedup when using an indexed technique.
IMO, speed is probably the top most important feature for a
cache.
Maybe it is off topic or quiet late, but what is your opinion
about Jcache ?
http://jcp.org/jsr/detail/107.jsp
> Yes. If you want that kind of ReplacementPolicy. Just implement it. and use
> like bellow.
well currently I dont really need it :D (that was just a
suggestion), but I'll try to propose something clean as soon as
I've finish my current work.
> final Cache cache = new DefaultCache( new TimeMapLRUCachePolicy(),
> MemoryCacheStore( 1000000000 ) );
>
> and test it.
> and send to this list.
no prob.
staytuned :)
--
mailto:alag@users.sourceforge.net -
http://sourceforge.net/projects/jabaserver
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: excalibur.cache.LRUCachePolicy
Posted by Eung-ju Park <co...@apache.org>.
Hi.
----- Original Message -----
From: "Alexis Agahi" <al...@agahi.com>
To: "'Avalon Developers List'" <av...@jakarta.apache.org>
Sent: Monday, January 07, 2002 8:17 AM
Subject: excalibur.cache.LRUCachePolicy
> Hi,
>
> I've checked the cache implementation from excalibur scratchpad
> and notice that LRUCachePolicy use the ListCachePolicy LinkedList
> to perform the LRU mecanism.
>
> To have a LRU 'hit' effect, it removes the object from the list
> and put it at the top.
> What if the list is really huge? I mean, to perform the remove it
It is not a Cache if it is really huge. ;-) Just kidding.
> has to scan the whole list, since it doesn't have an index (or
> I'm wrong)?
>
> I would suggest having another approach using a logical clock
> value and 'time' hashmap.
>
> Something like:
> When a 'hit' is called, it gets the current object and set its
> 'value' to the current logical time.
> To remove the oldest, it gets the oldest value in the time map.
>
> To be really honest, this approach is not necessarily the best:
> the remove case is slower that the linked list one, but the 'hit'
> could be faster. Now it depends on the hit/remove ratio. But I
> guess in an LRU cache, you should have a maximum of 'hit' call.
Yes. If you want that kind of ReplacementPolicy. Just implement it. and use
like bellow.
final Cache cache = new DefaultCache( new TimeMapLRUCachePolicy(),
MemoryCacheStore( 1000000000 ) );
and test it.
and send to this list.
Thanks.
>
>
> Regards
>
> --
> mailto:alag@users.sourceforge.net -
> http://sourceforge.net/projects/jabaserver
>
> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
> For additional commands, e-mail:
<ma...@jakarta.apache.org>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>