lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Earwin Burrfoot (JIRA)" <>
Subject [jira] Commented: (LUCENE-2840) Multi-Threading in IndexSearcher (after removal of MultiSearcher and ParallelMultiSearcher)
Date Sun, 09 Jan 2011 11:53:46 GMT


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:
>             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:
For additional commands, e-mail:

View raw message