[
https://issues.apache.org/jira/browse/LUCENE-1471?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12654529#action_12654529
]
Jason Rutherglen commented on LUCENE-1471:
------------------------------------------
The patches seem to implement the same concept? I'm using the 2nd one because
FieldDocSortedHitQueue is not public (it should be) and some other class is
final that made using the 1st patch impossible.
If there is no performance difference then the 1st patch is less code and
re-uses Lucene more so the 1st looks best.
Mike M:
"I agree performance improvement is probably smallish since m & n are
usually small; "
If results are in the hundreds then the performance matters. With more
microprocessor cores
growing because we don't have nanotech processors yet, parallel thread
searching should be the norm
for systems that care about response time.
> 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
> Assignee: Michael McCandless
> Priority: Minor
> Attachments: LUCENE-1471.patch, multisearcher.patch
>
> 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]
