Mailing-List: contact dev-help@lucene.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@lucene.apache.org
Message-ID: <13004787.96311276977983189.JavaMail.jira@thor>
Date: Sat, 19 Jun 2010 16:06:23 -0400 (EDT)
From: "Yonik Seeley (JIRA)" <jira@apache.org>
To: dev@lucene.apache.org
Subject: [jira] Commented: (LUCENE-2504) sorting performance regression
In-Reply-To: <32243998.96151276976723318.JavaMail.jira@thor>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


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

Yonik Seeley commented on LUCENE-2504:
--------------------------------------

My guess is that this is caused by LUCENE-2380, but I opened a separate issue since I'm not sure.
This is the same type of JVM performance issues reported by Mike in LUCENE-2143 and myself in LUCENE-2380.

Setup:
  Same test index I used to test faceting: 10M doc index with 5 fields:
   -  f100000_s:  a single valued string field with 100,000 unique values 
   -  f10000_s:   a single valued field with 10,000 unique values
   -  f1000_s:   a single valued field with 1000 unique values
   -  f100_s:   a single valued field with 100 unique values
   -  f10_s:   a single valued field with 10 unique values

URLs I tested against Solr are of the form:
http://localhost:8983/solr/select?q=*:*&rows=1&sort=f100000_s+asc

branch_3x
----------------------------------------------------------
 f100000_s sort only: 101 ms
sort against random field: 101 ms

trunk:
----------------------------------------------------------
 f100000_s sort only: 111 ms
sort against random field: 158 ms

This is not due to garbage collection or cache effects.  After you sort against a mix of fields, the performance is worse forever... you can go back to sorting against  f100000_s only, and the performance never recovers.

System: Ubuntu on Phenom II 4x3.0GHz, Java 1.6_20

So my guess is that this is caused by the ord lookup going through PagedBytes, and the JVM not optimizing away the indirection when there is a mix of implementations.


> sorting performance regression
> ------------------------------
>
>                 Key: LUCENE-2504
>                 URL: https://issues.apache.org/jira/browse/LUCENE-2504
>             Project: Lucene - Java
>          Issue Type: Bug
>    Affects Versions: 4.0
>            Reporter: Yonik Seeley
>             Fix For: 4.0
>
>
> sorting can be much slower on trunk than branch_3x

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