OK, thanks for running these. It looks like the gains are holding up across smaller queue sizes, and for ints. Though, it's odd that sorting w/ ints is also faster; I'd expect the single PQ to win there.
Mike On Thu, Oct 15, 2009 at 6:29 PM, John Wang <john.w...@gmail.com> wrote: > Numbers Mike requested for Int types: > > only the time/cputime are posted, others are all the same since the > algorithm is the same. > > Lucene 2.9: > numhits: 10 > time: 14619495 > cpu: 146126 > > numhits: 20 > time: 14550568 > cpu: 163242 > > numhits: 100 > time: 16467647 > cpu: 178379 > > > my test: > numHits: 10 > time: 14101094 > cpu: 144715 > > numHits: 20 > time: 14804821 > cpu: 151305 > > numHits: 100 > time: 15372157 > cpu time: 158842 > > Conclusions: > The are very similar, the differences are all within error bounds, > especially with lower PQ sizes, which second sort alg again slightly faster. > > Hope this helps. > > -John > > > On Thu, Oct 15, 2009 at 3:04 PM, Yonik Seeley <yo...@lucidimagination.com> > wrote: >> >> On Thu, Oct 15, 2009 at 5:33 PM, Michael McCandless >> <luc...@mikemccandless.com> wrote: >> > Though it'd be odd if the switch to searching by segment >> > really was most of the gains here. >> >> I had assumed that much of the improvement was due to ditching >> MultiTermEnum/MultiTermDocs. >> Note that LUCENE-1483 was before LUCENE-1596... but that only helps >> with queries that use a TermEnum (range, prefix, etc). >> >> -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 >> > > --------------------------------------------------------------------- To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org For additional commands, e-mail: java-dev-h...@lucene.apache.org
