Hmm - perhaps I'm not remembering right. Or perhaps we had different motivations ;) I never did anything in 1483 based on search perf - and I took your tests as testing that we didn't lose perf, not that we gained any. The fact that there were some wins was just a nice surprise from my perspective.
A quote from you in that issue: "I didn't expect such performance gain (I was hoping for not much performance loss, actually). I think it may be that although the initial value copy adds some cost, the within-queue comparsions are then faster because you don't have to deref back to the fieldcache array. It seems we keep accidentally discovering performance gains here" My whole memory of that issue is that we didn't do anything for performance gains. We just happened to measure a few. It was just to get to per segment. Was a long time ago though. Michael McCandless wrote: > On Tue, Oct 20, 2009 at 6:51 AM, Mark Miller <markrmil...@gmail.com> wrote: > >> I didn't really follow that thread either - but we didn't move to the new >> Comp Api because of it's perfomance vs the old. >> > > We did (LUCENE-1483), but those perf tests mixed in a number of other > improvements (eg, searching by segment avoids the 2nd pass of > MultiTermDocs.read(int[], int[]), whereas John's tests more > specifically test the perf difference between single-PQ vs > multi-PQ-then-merge (much simpler comparator API). > > So we are re-scrutinizing that difference... and if the perf gains are > minimal or non-existent I think we should still consider going back to > the simpler API. > > I'm working now to set up a full benchmark across real (wikipedia) / > synthetic source, different queries, different sorts, balanced vs > unbalanced segment sizes, etc. > > Mike > > --------------------------------------------------------------------- > To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: java-dev-h...@lucene.apache.org > > -- - Mark 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
