Mailing-List: contact dev-help@lucene.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@lucene.apache.org
Message-ID: <21743362.170101284437192755.JavaMail.jira@thor>
Date: Tue, 14 Sep 2010 00:06:32 -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=12909107#action_12909107 ] 

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

bq. Yonik, just curious, how do you know what HotSpot is doing? Empirically based on performance numbers?

Yeah - it's a best guess based on what I see when performance testing, and matching that up with what I've read in the past.
As far as deoptmization is concerned, it's mentioned here: http://java.sun.com/products/hotspot/whitepaper.html, but I haven't read much elsewhere.

Specific to this issue, the whole optimization/deoptimization issue is extremely complex.
Recall that I reported this: "Median response time in my tests drops from 160 to 102 ms."

For simplicity, there are some details I left out:
Those numbers were for randomly sorting on different fields (hopefully the most realistic scenario).
If you test differently, the results are far different.

The first and second test runs measured median time sorting on a single field 100 times in a row, then moving to the next field.

Trunk before patch:
|unique terms in field|median sort time in ms (first run)|second run
|100000|105|168
|10000|105|169
|1000|106|164
|100|127|163
|10|165|197

Trunk after patch:
|unique terms in field|median sort time in ms (first run)|second run
|100000|85|130
|10000|92|129
|1000|92|126
|100|116|127
|10|117|128

branch_3x
|unique terms in field|median sort time in ms (first run)|second run
|100000|102|102
|10000|102|103
|1000|101|103
|100|103|103
|10|118|118

So, it seems by running in batches (sorting on the same field over and over), we cause hotspot to overspecialize somehow, and then when we switch things up the resulting deoptimization puts us in a permanently worse condition).  branch_3x does not suffer from that, but trunk still does due to the increased amount of indirection.  I imagine the differences are also due to the boundaries that the compiler tries to inline/specialize for a certain class.

It certainly complicates performance testing, and we need to keep a sharp eye on how we actually test potential improvements.

> 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
>
>         Attachments: LUCENE-2504.patch, LUCENE-2504.patch, LUCENE-2504.zip
>
>
> 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