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
