[ http://issues.apache.org/jira/browse/LUCENE-443?page=all ]
Yonik Seeley resolved LUCENE-443.
-
Fix Version/s: 2.1
Resolution: Fixed
Assignee: Yonik Seeley
Thanks! I just committed this.
> ConjunctionScorer tune-up
> ---
I did some profile testing with the new ConjuctionScorer in 2.1 and
discovered a new bottleneck in ConjunctionScorer.sortScorers. The
java.utils.Arrays.sort method is cloning the Scorers array on every sort,
which is quite expensive on large indexes because of the size of the 'norms'
array within,
On 10/23/06, Peter Keegan <[EMAIL PROTECTED]> wrote:
I did some profile testing with the new ConjuctionScorer in 2.1 and
discovered a new bottleneck in ConjunctionScorer.sortScorers. The
java.utils.Arrays.sort method is cloning the Scorers array on every sort,
Huh... that's interesting. I wond
On Monday 23 October 2006 22:12, Peter Keegan wrote:
> I did some profile testing with the new ConjuctionScorer in 2.1 and
> discovered a new bottleneck in ConjunctionScorer.sortScorers. The
> java.utils.Arrays.sort method is cloning the Scorers array on every sort,
> which is quite expensive on la
Huh... that's interesting. I wonder why Arrays.sort(int[]) is all
in-place but sort(Object[]) is not.
I was wondering that myself. Here's the code:
public static void sort(T[] a, Comparator c) {
T[] aux = (T[])a.clone();
if (c==null)
mergeSort(aux, a, 0, a.length, 0);
Isn't the issue the creation of a new Comparator each time the scorers
are sorted? That could be easily fixed by keeping single comparator
around to do all the work.
Yes, it's the Comparator, but I think even if you kept it around, the
Array.sort would still clone the Scorers, no?
Peter
On 10/2
Can you open a JIRA issue for this?
Yes, it's: http://issues.apache.org/jira/browse/LUCENE-693
Peter
