Sort.INDEXORDER just lets you know about matching documents while by default a score is computed and Lucene selects the top N matching documents from your index.
On Mon, Sep 9, 2013 at 7:33 PM, Mirko Sertic <mirko.ser...@web.de> wrote: > Ok, using Sort.INDEXORDER for default sorting is blazing fast. Just for my > understanding, what is the difference between both methods? Is just > unneccesary score computation the problem of the CPU peak? > > Thanks in advance > Mirko > > Am 09.09.2013 13:43, schrieb Michael McCandless: > >> 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 >> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: java-user-unsubscr...@lucene.apache.org > For additional commands, e-mail: java-user-h...@lucene.apache.org > -- Adrien --------------------------------------------------------------------- To unsubscribe, e-mail: java-user-unsubscr...@lucene.apache.org For additional commands, e-mail: java-user-h...@lucene.apache.org
