[
https://issues.apache.org/jira/browse/LUCENE-3738?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13242550#comment-13242550
]
Michael McCandless commented on LUCENE-3738:
--------------------------------------------
Removing the asserts apparently didn't change the perf...
I can reproduce the slowdown in a separate test (before/after this commit):
{noformat}
Task QPS base StdDev base QPS vInt StdDev vInt Pct
diff
IntNRQ 7.11 0.89 6.73 0.58 -23% -
17%
Prefix3 16.07 0.96 15.65 0.72 -12% -
8%
Wildcard 20.14 0.91 19.67 0.77 -10% -
6%
PKLookup 154.62 5.08 151.11 2.82 -7% -
2%
Fuzzy1 85.24 1.53 83.87 1.18 -4% -
1%
Fuzzy2 44.11 1.03 43.96 0.44 -3% -
3%
SpanNear 3.23 0.11 3.22 0.07 -5% -
5%
TermBGroup1M1P 42.35 0.49 42.43 1.43 -4% -
4%
Respell 65.11 1.91 65.27 1.27 -4% -
5%
AndHighMed 54.18 4.04 54.50 2.27 -10% -
13%
TermGroup1M 31.27 0.35 31.46 0.63 -2% -
3%
TermBGroup1M 45.01 0.33 45.37 1.42 -3% -
4%
AndHighHigh 13.35 0.71 13.46 0.50 -7% -
10%
Term 82.71 3.12 83.56 2.33 -5% -
7%
OrHighMed 10.66 0.67 10.78 0.44 -8% -
12%
OrHighHigh 7.08 0.42 7.19 0.26 -7% -
11%
SloppyPhrase 5.11 0.24 5.20 0.31 -8% -
13%
Phrase 11.14 0.75 11.40 0.50 -8% -
14%
{noformat}
But then Uwe made a patch (I'll attach) reducing the byte code for the
unrolled methods:
{noformat}
Task QPS base StdDev base QPS vInt StdDev vInt Pct
diff
SpanNear 3.24 0.13 3.18 0.07 -7% -
4%
Phrase 11.34 0.68 11.13 0.38 -10% -
7%
SloppyPhrase 5.17 0.23 5.08 0.18 -9% -
6%
TermBGroup1M1P 41.92 0.80 41.57 0.94 -4% -
3%
TermGroup1M 30.74 0.68 30.81 0.96 -5% -
5%
Term 80.87 3.52 81.29 2.05 -6% -
7%
TermBGroup1M 43.94 0.93 44.17 1.32 -4% -
5%
AndHighMed 53.71 2.62 54.21 1.97 -7% -
9%
AndHighHigh 13.20 0.42 13.41 0.41 -4% -
8%
Respell 65.37 2.70 66.53 3.29 -7% -
11%
Fuzzy1 84.29 2.11 86.44 3.36 -3% -
9%
PKLookup 149.81 4.20 153.87 9.46 -6% -
12%
OrHighHigh 7.19 0.28 7.40 0.48 -7% -
13%
OrHighMed 10.82 0.43 11.16 0.73 -7% -
14%
Fuzzy2 43.72 0.96 45.24 2.03 -3% -
10%
Wildcard 18.96 1.00 20.05 0.39 -1% -
13%
Prefix3 14.96 0.83 15.89 0.27 -1% -
14%
IntNRQ 5.89 0.58 6.95 0.17 4% -
34%
{noformat}
So... I think we should commit it!
> Be consistent about negative vInt/vLong
> ---------------------------------------
>
> Key: LUCENE-3738
> URL: https://issues.apache.org/jira/browse/LUCENE-3738
> Project: Lucene - Java
> Issue Type: Bug
> Reporter: Michael McCandless
> Assignee: Uwe Schindler
> Fix For: 3.6, 4.0
>
> Attachments: ByteArrayDataInput.java.patch, LUCENE-3738.patch,
> LUCENE-3738.patch, LUCENE-3738.patch, LUCENE-3738.patch, LUCENE-3738.patch
>
>
> Today, write/readVInt "allows" a negative int, in that it will encode and
> decode correctly, just horribly inefficiently (5 bytes).
> However, read/writeVLong fails (trips an assert).
> I'd prefer that both vInt/vLong trip an assert if you ever try to write a
> negative number... it's badly trappy today. But, unfortunately, we sometimes
> rely on this... had we had this assert in 'since the beginning' we could have
> avoided that.
> So, if we can't add that assert in today, I think we should at least fix
> readVLong to handle negative longs... but then you quietly spend 9 bytes
> (even more trappy!).
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
