lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Yonik Seeley (JIRA)" <j...@apache.org>
Subject [jira] Commented: (LUCENE-2504) sorting performance regression
Date Tue, 14 Sep 2010 04:06:32 GMT

    [ 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


Mime
View raw message