[
https://issues.apache.org/jira/browse/LUCENE-1997?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12771923#action_12771923
]
Michael McCandless commented on LUCENE-1997:
--------------------------------------------
JAVA:
java version "1.6.0_14"
Java(TM) SE Runtime Environment (build 1.6.0_14-b08)
Java HotSpot(TM) 64-Bit Server VM (build 14.0-b16, mixed mode)
OS:
SunOS rhumba 5.11 snv_111b i86pc i386 i86pc Solaris
||Source||Seg size||Query||Tot hits||Sort||Top N||QPS old||QPS new||Pct change||
|wiki|log|1|1170209|rand int|10|27.08|27.52|{color:green}1.6%{color}|
|wiki|log|1|1170209|rand int|25|26.95|27.72|{color:green}2.9%{color}|
|wiki|log|1|1170209|rand int|50|27.54|27.03|{color:red}-1.9%{color}|
|wiki|log|1|1170209|rand int|100|27.08|24.19|{color:red}-10.7%{color}|
|wiki|log|1|1170209|rand int|500|26.13|26.88|{color:green}2.9%{color}|
|wiki|log|1|1170209|rand int|1000|24.30|25.91|{color:green}6.6%{color}|
|wiki|log|2|1088727|rand int|10|29.66|29.45|{color:red}-0.7%{color}|
|wiki|log|2|1088727|rand int|25|28.80|29.47|{color:green}2.3%{color}|
|wiki|log|2|1088727|rand int|50|29.57|30.21|{color:green}2.2%{color}|
|wiki|log|2|1088727|rand int|100|30.74|27.30|{color:red}-11.2%{color}|
|wiki|log|2|1088727|rand int|500|28.72|30.17|{color:green}5.0%{color}|
|wiki|log|2|1088727|rand int|1000|27.20|29.21|{color:green}7.4%{color}|
|wiki|log|<all>|5000000|rand int|10|33.43|31.09|{color:red}-7.0%{color}|
|wiki|log|<all>|5000000|rand int|25|33.24|31.77|{color:red}-4.4%{color}|
|wiki|log|<all>|5000000|rand int|50|32.89|31.68|{color:red}-3.7%{color}|
|wiki|log|<all>|5000000|rand int|100|32.04|21.33|{color:red}-33.4%{color}|
|wiki|log|<all>|5000000|rand int|500|31.25|30.59|{color:red}-2.1%{color}|
|wiki|log|<all>|5000000|rand int|1000|29.48|29.72|{color:green}0.8%{color}|
|random|log|<all>|5000000|rand int|10|32.61|31.64|{color:red}-3.0%{color}|
|random|log|<all>|5000000|rand int|25|32.98|31.79|{color:red}-3.6%{color}|
|random|log|<all>|5000000|rand int|50|32.63|30.89|{color:red}-5.3%{color}|
|random|log|<all>|5000000|rand int|100|32.08|21.60|{color:red}-32.7%{color}|
|random|log|<all>|5000000|rand int|500|30.48|30.65|{color:green}0.6%{color}|
|random|log|<all>|5000000|rand int|1000|28.95|29.44|{color:green}1.7%{color}|
This table compares trunk (= old) with the "inline int value directly into
single PQ" approach (=new). So, a green result means the inline-single-PQ is
faster; red means it's slower.
The results baffle me. I would have expected for the 5M hits, with shallow
topN, that the diffs would be minor since the sub-leading cost should be in the
noise for either approach, and then as we go to fewer hits and deeper topN,
that the inline-single-PQ approach would be faster. And, we still see
strangeness at topN=100 where current trunk is always substantially better.
The only difference between these ought to be the constant in front of the net
number of inserstions. Strange!
> 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: [email protected]
For additional commands, e-mail: [email protected]
