[
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: [email protected]
For additional commands, e-mail: [email protected]
