On 3/9/07, David Johnson <[EMAIL PROTECTED]> wrote:
-- snip -- yes, this should ensure that caching in lucene is used wherever possible. > Even > though there might be bugs that prevent this. Just like this one: > > http://svn.apache.org/viewvc?view=rev&revision=506908 > > which prevented the re-use of SharedFiledSortComparator even if nothing > changed > between two query execution calls. You might want to check if this patch > improves the situation for you.
I thought I would report some profiling results with the above patch installed. Like I reported earlier, this patch helps query performance significantly, and I hope it will make it into a release very soon. With the patch, profiling is showing a very different picture than what I reported earlier in this thread: Out of the Jackrabbit code, DescendantSelfAxisQuery.DescendantSelfAxisScorer.next() is now taking the most time while executing my query suite - taking 68% of the time, within it, calls to DescendantSelfAxisQuery.DescendantSelfAxisScorer.calculateSubHits() taking the majority of time (basically all of the time). Then calls to BooleanScorer2.score(HitCollector) - back to Lucene code - is taking the majority of time. If more specific profiling data is desired, please feel free to ask. I can also share the profile data in the form of a Netbeans profile snapshot. Any magic patch that might address these performance bottlenecks? At this point it doesn't look like the range queries are the issue anymore. -Dave
