Sort.INDEXORDER, or, just make your own Collector, which should be faster than INDEXORDER.
Mike McCandless http://blog.mikemccandless.com On Mon, Sep 9, 2013 at 7:19 AM, Mirko Sertic <mirko.ser...@web.de> wrote: > Dear Mike > > I need an API to disable Scoring without any sorting. > > Unfortunately every method in IndexSearcher where i can say doDocScores also > require a not-null Sort instance. So what would be the best way to disable > scoring and have no sorting, and archiving the same performance as the "Empty > Sort()" bug? I should probably use Sort.INDEXORDER for sorting, right? It > gives me the same result... > > Thanks in advance > Mirko > > > > Gesendet: Montag, 09. September 2013 um 13:03 Uhr > Von: "Michael McCandless" <luc...@mikemccandless.com> > An: "Lucene Users" <java-user@lucene.apache.org> > Betreff: Re: Re: Re: Strange performance of Lucene 4.4.0 > If new Sort() fails to sort by score, that's a bug! Can you please > open a Jira issue? > > Mike McCandless > > http://blog.mikemccandless.com > > > On Mon, Sep 9, 2013 at 5:21 AM, Mirko Sertic <mirko.ser...@web.de> wrote: >> Hi >> >> Basically i am running a load test. For every run i executed about 1 million >> queries on the same index with the same query string, so it should be warmed >> up very well ;-) It performs about 8x faster with an empty Sort() instance >> than the first option. Still do not get it. An empty Sort instance should >> sort by score, according to the default constructor. >> >> Providing no sort instance finally invokes >> >> protected TopDocs search(Weight weight, ScoreDoc after, int nDocs) throws >> IOException >> >> while providing a Sort instance finally invokes >> >> protected TopFieldDocs search(Weight weight, FieldDoc after, int nDocs, >> Sort sort, boolean fillFields, >> boolean doDocScores, boolean doMaxScore) throws IOException >> >> with doDocScores and doMaxScore set to false. >> >> Seems like providing an empty Sort() instances should sort by score >> according to its default constructor. But no scoring is done by the >> IndexSearcher, so there is nothing so sort at all. So from this point of >> view the scoring computation does cause the slower queries. >> >> Regards >> Mirko >> >> Gesendet: Montag, 09. September 2013 um 09:55 Uhr >> Von: "Toke Eskildsen" <t...@statsbiblioteket.dk> >> An: "java-user@lucene.apache.org" <java-user@lucene.apache.org> >> Betreff: Re: Aw: Re: Strange performance of Lucene 4.4.0 >> On Sun, 2013-09-08 at 15:15 +0200, Mirko Sertic wrote: >>> I have to check, but my usecase does not require sorting or even >>> scoring at all. I still do not get what the difference is... >> >> Please describe how you perform your measurements. How do you ensure >> that the index is warmed equally for the two cases? >> >> - Toke >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: java-user-unsubscr...@lucene.apache.org >> For additional commands, e-mail: java-user-h...@lucene.apache.org >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: java-user-unsubscr...@lucene.apache.org >> For additional commands, e-mail: java-user-h...@lucene.apache.org >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: java-user-unsubscr...@lucene.apache.org > For additional commands, e-mail: java-user-h...@lucene.apache.org > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: java-user-unsubscr...@lucene.apache.org > For additional commands, e-mail: java-user-h...@lucene.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: java-user-unsubscr...@lucene.apache.org For additional commands, e-mail: java-user-h...@lucene.apache.org
