jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "David Johnson" <dbjohnso...@gmail.com>
Subject Re: Query Performance and Optimization
Date Mon, 12 Mar 2007 02:00:20 GMT
On 3/9/07, David Johnson <dbjohnson.e@gmail.com> 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.


  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message