[LUCENE-1997] Explore performance of multi-PQ vs single-PQ sorting API

• Type: Improvement
• Status: Reopened
• Priority: Major
• Resolution: Unresolved
• Affects Version/s: 2.9
• Component/s: core/search
• Lucene Fields: New
• Assignee: Michael McCandless
• Reporter: Michael McCandless
• Created: 20/Oct/09 15:02
• Updated: 28/Aug/22 12:12

Description

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.