lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Erik Hatcher <e...@ehatchersolutions.com>
Subject Re: RE : DateFilter.Before/After
Date Mon, 15 Sep 2003 14:27:27 GMT
On Monday, September 15, 2003, at 09:45  AM, Bruce Ritchie wrote:
> I would suggest *not* using caching inside of filters provided by 
> lucene but rather provide a wrapper to do the caching. The reason is 
> that some applications really don't want the libraries they use to be 
> a source of concern for memory usage. i.e. if I search for a string 
> using 10,000 different date filters (an extreme example, but possible) 
> I want the ability to control how those bitsets are going to be > cached.

In the case of QueryFilter, simply construct a new one to avoid caching 
rather than reuse the same instance.  So you have control there as 
well.  The only thing that is cached is a BitSet, so it should be much 
of a memory usage concern.

> public class CachedFilter extends Filter {
>     BitSet bits;
>     Filter filter;
>
>     public CachedFilter(Filter filter) {
>         this.filter = filter;
>         this.bits = null;
>     }
>
>     public BitSet bits(IndexReader reader) throws IOException {
>         if (bits != null) {
>             return bits;
>         }
>
>         bits = filter.bits(reader);
>         return bits;
>     }
> }

You would have problems if you searched a different index or different 
instance of IndexReader even with your caching here.  You should cache 
like QueryFilter does to avoid a potential mismatch with IndexReader 
instances.

But you're implementation is exactly what I was envisioning with the 
added WeakHashMap of QueryFilter.

	Erik


Mime
View raw message