avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Eung-ju Park" <co...@apache.org>
Subject Re: Cache Performance
Date Tue, 08 Jan 2002 08:20:49 GMT

----- Original Message -----
From: "Antti Koivunen" <anryoshi@users.sourceforge.net>
To: <avalon-dev@jakarta.apache.org>
Sent: Tuesday, January 08, 2002 4:18 AM
Subject: Cache Performance


>
> As caching is used to improve application performance, the cache
> operations themselves should be as fast as possible. While I like the
> modular design of the proposed Excalibur cache, there are a few issues
> that can potentially limit the performance.
>
>
> 1. The Cache interface is a bit too heavy
>
> Most components use cache just as a 'place to put get things from', so
> they have no need for cache listeners. Some might also want to decide
> for themselves if an element is to be considered valid, without having
> to encapsulate this functionality in CacheValidators.
>
> Would it make sense to limit Cache to provide just the necessary
> methods, and extend this with a ValidatingCache to support event
> listeners and pluggable CacheValidators? Actually, it would be even
> possible to define a
>
>    ValidatingCacheProxy(Cache cache, CacheValidator validator)
>
> that would provide this functionality to any cache implementation,
> without sacrificing performance when it's not needed.

Yes.

>
>
> 2. Cache should probably not extend ThreadSafe
>
> While 97% of all applications need a thread-safe cache, this is not
> always the case. For example, in performance sensitive event-driven
> architectures, there might be a single worker thread using the cache
> that really doesn't need the additional cost of acquiring and releasing
> object locks.
>
> Naturally, it would be possible to define a synch proxy to turn any
> unsynchronized Cache into a thread-safe one.
>

Yes.

>
> 3. Cache + CacheStore + ReplacementPolicy
>
> I really like the good separation of concerns. However, this does have
> some performace implications as these components could be tightly
> integrated. This is of course just a minor implementation detail (not
> required by the Cache interface).

Yes. CacheStore and ReplacementPolicy is not required by Cache.

>
> BTW, probably the best way to implement LRUPolicy, would be to use a
> custom linked list backed by a HashMap to hold the entries for quick
> lookups.
>
>
> 4. Good work, that's all :)
>
> All things considered, very nice OOD.
>
>
> Thanks for reading my first post on this list. Hopefully it wasn't a
> complete waste of your time.
>
> (: Anrie ;)

Thanks for your suggestion. I will be reflect your suggestion. ;-)

>
>
>
> --
> To unsubscribe, e-mail:
<mailto:avalon-dev-unsubscribe@jakarta.apache.org>
> For additional commands, e-mail:
<mailto:avalon-dev-help@jakarta.apache.org>
>
>


--
To unsubscribe, e-mail:   <mailto:avalon-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:avalon-dev-help@jakarta.apache.org>


Mime
View raw message