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)[EMAIL PROTECTED]'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
