lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Uwe Schindler (JIRA)" <j...@apache.org>
Subject [jira] Commented: (LUCENE-2006) Optimization for FieldDocSortedHitQueue
Date Fri, 23 Oct 2009 22:53:59 GMT

    [ https://issues.apache.org/jira/browse/LUCENE-2006?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12769515#action_12769515
] 

Uwe Schindler commented on LUCENE-2006:
---------------------------------------

I think it is because you only merge the top 1000 docs into the HitQueue. The merging of the
HQs at the end of search is simple, because it only merges the top n docs of each queue. You
would only see a difference if you sort all hits.

I think we can commit this, too.

> Optimization for FieldDocSortedHitQueue
> ---------------------------------------
>
>                 Key: LUCENE-2006
>                 URL: https://issues.apache.org/jira/browse/LUCENE-2006
>             Project: Lucene - Java
>          Issue Type: Improvement
>          Components: Search
>    Affects Versions: 3.0
>            Reporter: Uwe Schindler
>            Assignee: Uwe Schindler
>             Fix For: 3.0
>
>         Attachments: LUCENE-2006.patch
>
>
> When updating core for generics,  I found the following as a optimization of FieldDocSortedHitQueue:
> All FieldDoc values are Compareables (also the score or docid, if they
> appear as SortField in a MultiSearcher or ParallelMultiSearcher). The code
> of lessThan seems very ineffective, as it has a big switch statement on the
> SortField type, then casts the value to the underlying numeric type Object,
> calls Number.xxxValue() & co for it and then compares manually. As
> j.l.Number is itself Comparable, I see no reason to do this. Just call
> compareTo on the Comparable interface and we are happy. The big deal is that
> it prevents casting and the two method calls xxxValue(), as Number.compareTo
> works more efficient internally.
> The only special cases are String sort, where the Locale may be used and the
> score sorting which is backwards. But these are two if statements instead of
> the whole switch.
> I had not tested it now for performance, but in my opinion it should be
> faster for MultiSearchers. All tests still pass (because they should).

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


Mime
View raw message