Mailing-List: contact dev-help@lucene.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@lucene.apache.org
Message-ID: <14288806.238301294574026583.JavaMail.jira@thor>
Date: Sun, 9 Jan 2011 06:53:46 -0500 (EST)
From: "Earwin Burrfoot (JIRA)" <jira@apache.org>
To: dev@lucene.apache.org
Subject: [jira] Commented: (LUCENE-2840) Multi-Threading in IndexSearcher
 (after removal of MultiSearcher and ParallelMultiSearcher)
In-Reply-To: <2041681.70501293710326235.JavaMail.jira@thor>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ 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-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org