Erik Hatcher wrote:
Also, regarding DateFilter.... would it be reasonable to apply the same bitset caching that QueryFilter uses?
what about a CachingFilterWrapper implementation that implements Filter and the QueryFilter-like caching, and passes through to another filter for the actual gathering of the bitset?
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. Yes, I realize that a weakhashmap can and is used by the QueryFilter however I think it's best if the client application does the caching as only it is best suited to know what should and should not be cached. It's dead simple for the client app to just do the lookup of the filter against a key in the hashmap.
I use the following - it's simple and effective.
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;
}
}Regards,
Bruce Ritchie
smime.p7s
Description: S/MIME Cryptographic Signature
