[
https://issues.apache.org/jira/browse/LUCENE-1471?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12651876#action_12651876
]
Luke Nezda commented on LUCENE-1471:
------------------------------------
I had a look at this code and it looks like an easy opportunity. Here's my
analysis
* let m = searchables.length
* let n = nDocs
- Current performance: n * m * lg( n )
n * m * lg( n ) + // fill queue
n * lg( n ) // drain queue into scoreDocs[]
if each searcher read has n worse documents than the one before it
- Possible performance: n * lg( m )
m * lg( m ) + // init queue
n * lg( m ) + // drain & fill queue
I'll attach a patch for {{MultiSearcher}} {{search()}} methods that supports
with and without {{Sort}}. Its a little kludgy - had to remove {{final}} from
{{FieldDocSortedHitQueue}}'s {{lessThan}} method and do some casting. All
tests pass. I doubt much search time is tied up here since this is all
in-memory and n and m are usually small.
> Faster MultiSearcher.search merge docs
> ---------------------------------------
>
> Key: LUCENE-1471
> URL: https://issues.apache.org/jira/browse/LUCENE-1471
> Project: Lucene - Java
> Issue Type: Improvement
> Components: Search
> Affects Versions: 2.4
> Reporter: Jason Rutherglen
> Priority: Minor
> Original Estimate: 8h
> Remaining Estimate: 8h
>
> MultiSearcher.search places sorted search results from individual searchers
> into a PriorityQueue. This can be made to be more optimal by taking
> advantage of the fact that the results returned are already sorted.
> The proposed solution places the sub-searcher results iterator into a custom
> PriorityQueue that produces the sorted ScoreDocs.
--
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]
