lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Yonik Seeley <yo...@lucidimagination.com>
Subject Re: lucene 2.9 sorting algorithm
Date Fri, 23 Oct 2009 03:30:52 GMT
On Thu, Oct 22, 2009 at 11:11 PM, Jake Mannix <jake.mannix@gmail.com> wrote:
> It's hard to read the column format, but if you look up above in the thread
> from tonight,
> you can see that yes, for PQ sizes less than 100 elements, multiPQ is
> better, and only
> starts to be worse at around 100 for strings, and 50 for ints.

Ah, OK, I had missed John's followup with the numbers.

I assume this is for Java5 + optimizations?
What does Java6 show?

bq. Point 2 does indeed make a difference, we've seen it, and it's
only fair: the single pq comparator does this branch optimization but
the current patch multi-pq does not, so let's level the playing field.

Of course - it's not about leveling the playing field, but finding the
best solution for the average case - so everything should be optimized
as much as possible.  There are probably further optimizations
possible in both the single and multi PQ cases.

My biggest reservation is that we've gone down the road of telling
people to implement a new style of comparators, and told them that the
old style comparators would be deleted in the next release (which is
where we are).  Reversing that will be a bit of a headache/question...
the new stuff isn't deprecated, and having *both* isn't desirable, but
that's a separate decision to be made apart from performance testing.

Is there also an option of using a multiPQ approach with the new style
comparators?

-Yonik
http://www.lucidimagination.com

---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org


Mime
View raw message