[
https://issues.apache.org/jira/browse/LUCENE-1997?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12773012#action_12773012
]
Michael McCandless commented on LUCENE-1997:
--------------------------------------------
bq. Another observation, with multiQ approach, seems there would be no need for
the set of OutOfOrder*Comparators.
I think it'd still be beneficial to differentiate In vs OutOf order collectors,
because even within 1 segment if you know the docIDs arrive in order then the
compare bottom is cheaper (need not break ties).
bq. Even with 100 segment which I am guessing you agree that it is rare, it is
400K,
Don't forget that this is multiplied by however many queries are currently in
flight.
Yonik also raised an important difference of the single PQ API (above:
https://issues.apache.org/jira/browse/LUCENE-1997?focusedCommentId=12771008&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#action_12771008),
ie, the fact that it references "slots" instead of "docid" means you can cache
something private in your "slots" based on previous compare/copy.
Since each approach has distinct advantages, why not offer both ("simple" and
"expert") comparator extensions APIs?
> Explore performance of multi-PQ vs single-PQ sorting API
> --------------------------------------------------------
>
> Key: LUCENE-1997
> URL: https://issues.apache.org/jira/browse/LUCENE-1997
> Project: Lucene - Java
> Issue Type: Improvement
> Components: Search
> Affects Versions: 2.9
> Reporter: Michael McCandless
> Assignee: Michael McCandless
> Attachments: LUCENE-1997.patch, LUCENE-1997.patch, LUCENE-1997.patch,
> LUCENE-1997.patch, LUCENE-1997.patch, LUCENE-1997.patch, LUCENE-1997.patch,
> LUCENE-1997.patch, LUCENE-1997.patch
>
>
> Spinoff from recent "lucene 2.9 sorting algorithm" thread on java-dev,
> where a simpler (non-segment-based) comparator API is proposed that
> gathers results into multiple PQs (one per segment) and then merges
> them in the end.
> I started from John's multi-PQ code and worked it into
> contrib/benchmark so that we could run perf tests. Then I generified
> the Python script I use for running search benchmarks (in
> contrib/benchmark/sortBench.py).
> The script first creates indexes with 1M docs (based on
> SortableSingleDocSource, and based on wikipedia, if available). Then
> it runs various combinations:
> * Index with 20 balanced segments vs index with the "normal" log
> segment size
> * Queries with different numbers of hits (only for wikipedia index)
> * Different top N
> * Different sorts (by title, for wikipedia, and by random string,
> random int, and country for the random index)
> For each test, 7 search rounds are run and the best QPS is kept. The
> script runs singlePQ then multiPQ, and records the resulting best QPS
> for each and produces table (in Jira format) as output.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: java-dev-h...@lucene.apache.org
