----- Original Message ----- From: "Antti Koivunen" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> 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:[EMAIL PROTECTED]> > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> > > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
