BTW, we are have a little sandbox for these experiments. And all my testcode are at. They are not very polished.
https://lucene-book.googlecode.com/svn/trunk -John On Thu, Oct 15, 2009 at 3: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 >> >> >
