On Thu, Oct 22, 2009 at 11:11 PM, Jake Mannix <jake.man...@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-unsubscr...@lucene.apache.org For additional commands, e-mail: java-dev-h...@lucene.apache.org
