[
https://issues.apache.org/jira/browse/LUCENE-2840?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12979306#action_12979306
]
Earwin Burrfoot commented on LUCENE-2840:
-----------------------------------------
A lot of fork-join type frameworks don't even care. Even though scheduling
threads is something people supposedly use them for.
Why? I guess that's due to low yield/cost ratio.
You frequently quote "progress, not perfection" in relation to the code, but
why don't we apply this same principle to our threading guarantees?
I don't want to use allowed concurrency fully. That's not realistic. I want 85%
of it. That's already a huge leap ahead of single-threaded searches.
> Multi-Threading in IndexSearcher (after removal of MultiSearcher and
> ParallelMultiSearcher)
> -------------------------------------------------------------------------------------------
>
> Key: LUCENE-2840
> URL: https://issues.apache.org/jira/browse/LUCENE-2840
> Project: Lucene - Java
> Issue Type: Sub-task
> Components: Search
> Reporter: Uwe Schindler
> Priority: Minor
> Fix For: 4.0
>
>
> Spin-off from parent issue:
> {quote}
> We should discuss about how many threads should be spawned. If you have an
> index with many segments, even small ones, I think only the larger segments
> should be separate threads, all others should be handled sequentially. So
> maybe add a maxThreads cound, then sort the IndexReaders by maxDoc and then
> only spawn maxThreads-1 threads for the bigger readers and then one
> additional thread for the rest?
> {quote}
--
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: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
