[
https://issues.apache.org/jira/browse/LUCENE-1471?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12654546#action_12654546
]
Michael McCandless commented on LUCENE-1471:
--------------------------------------------
bq. The patches seem to implement the same concept?
That's my impression.
bq. 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.
The first patch works fine, w/o making FieldDocSortedHitQueue public.
bq. If there is no performance difference then the 1st patch is less code and
re-uses Lucene more so the 1st looks best.
OK I'll go forwards with the first patch.
{quote}
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.
{quote}
I would love to find a clean way to make Lucene's searching "naturally"
concurrent, so that more cores would in fact greatly reduce the worst case
latency. Our inability to properly use concurrency on the search side to
reduce a single query's latency (we can of course use concurrency to improve
net throughput, today) will soon be a big limitation. ParallelMultiSearcher
ought to work, but it requires you to manually partition. And it should pool
threads or use ExecutorService. But I don't see how this applies to this
issue...
> 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]
