[
https://issues.apache.org/jira/browse/LUCENE-1997?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12772798#action_12772798
]
Mark Miller commented on LUCENE-1997:
-------------------------------------
bq. The point of discussion is memory, unless a few hundred K of memory
consumption implies a "huge perf drop". (I see you are being conservative and
using only 1 huge )
I know, I was purposely avoiding getting into the mem argument and just
focusing on how rare the situation is. And whether there is going to be a huge
perf drop with queue sizes of 1000, I just don't know. The tests have been
changing a lot - which is why I think its a little early to come to final
conclusions.
bq. Even with 100 segment which I am guessing you agree that it is rare, it is
400K, (in this discussion, I am using it as an upper bound, perhaps I should
state it more explicitly) and thus my inability to understand that being a
memory concern.
Yes - I do agree its rare.
bq. BTW, I am interested the percentage of "deep paging" you are seeing. You
argue it is not rare, do you have some concrete numbers? The stats I have seen
from our production logs and also web search logs when I was working on that,
the percentage is very very very very very (5 very's) low. (sharp drop usually
is at page 4, let alone page 100)
I don't have numbers I can share - but this isn't for situations with users
paging through an interface (like a web search page) - its users that are using
Lucene for other tasks - and there are plenty of those. Lucene is used a lot
for websites with users click through 10 results at a time - but its also used
in many, many other apps (and I do mean two manys ! :) )
> 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
