[ https://issues.apache.org/jira/browse/LUCENE-2006?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12769509#action_12769509 ]
Mark Miller commented on LUCENE-2006: ------------------------------------- Okay Uwe - I took a 2 GB zipped Wiki dump and used a SkipDocTask to create four unique indices of 64,000 docs each. Then I ran a search matching all docs and sorting on title, taking the average of 1000 runs and recording that overage over a few times for each method. I tried topn's of 10, 100, and 1000. I couldn't measure a meaningful difference one way or the other. Lets do it. > 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-unsubscr...@lucene.apache.org For additional commands, e-mail: java-dev-h...@lucene.apache.org