jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marcel Reutegger <marcel.reuteg...@gmx.net>
Subject Re: Commented: (JCR-791) Cache BitSet per IndexReader in MatchAllScorer
Date Mon, 19 Mar 2007 08:15:47 GMT
Hi Christoph,

Christoph Kiehl wrote:
> The effect of caching should increase if you use queries which test an 
> attribute more than once, like:
> 
> //element(*, nt:unstructured)[@foo!='1' or @foo!='2' or @foo!='3']
> 
> May be we can add a configuration option to SearchIndex which allows to 
> enable caching? This, way one can choose if his/her focus is on memory 
> or on processing time. We have a situation for example where a lot of 
> memory is available but processing time is the bottleneck.

I agree. and it makes a lot of sense to cache the BitSet at least for the time 
of the query execution. I personally try to avoid caches, unless the performance 
improvement is significant. With every cache we introduce we need to make sure 
that it does not use up all memory. The simple cache in MatchAllScorer I used 
for testing does not take care of that. If we introduce a cache there we would 
have to add some more code to integrate it into the CacheManager.

> Would you mind sharing a patch for the caching you implemented? Do you 
> may be even have a testcase which generates this test repository? I 
> could do some further tests here ..

I'll them to the jira issue, once jira is up and running again...

regards
  marcel

Mime
View raw message