ByteBuffer performance issue in Java 9?
Michael McCandless
lucene at mikemccandless.com
Sun Mar 12 21:15:25 UTC 2017
Hi Uwe,
I ran the standard luceneutil Wikipedia benchmark (same as what's run
nightly at https://home.apache.org/~mikemccand/lucenebench).
I compared Java 1.8.0_121 (base, below) and Java 9 ea 160 (comp), indexing
and searching all Wikipedia English content, using MMapDirectory, and
net/net there is some smallish slowdown, but it's not catastrophic.
I'm not sure why sloppy phrase queries are particularly hit. This was
after 20 JVM iterations:
Task QPS base StdDev QPS comp
StdDev Pct diff
LowSloppyPhrase 11.02 (6.0%) 9.17
(3.1%) -16.8% ( -24% - -8%)
HighSloppyPhrase 7.40 (4.5%) 6.36
(2.9%) -14.1% ( -20% - -6%)
MedSloppyPhrase 5.13 (4.3%) 4.48
(2.4%) -12.7% ( -18% - -6%)
HighTerm 44.54 (5.6%) 39.01
(3.6%) -12.4% ( -20% - -3%)
OrHighLow 39.53 (7.1%) 34.70
(4.9%) -12.2% ( -22% - 0%)
MedTerm 86.34 (5.2%) 75.88
(3.3%) -12.1% ( -19% - -3%)
OrHighNotLow 52.00 (7.1%) 46.10
(6.0%) -11.3% ( -22% - 1%)
BrowseDayOfYearSSDVFacets 5.33 (3.3%) 4.76
(5.8%) -10.6% ( -19% - -1%)
HighTermDayOfYearSort 20.49 (5.5%) 18.36
(5.8%) -10.4% ( -20% - 1%)
BrowseMonthTaxoFacets 1.47 (2.2%) 1.35
(6.8%) -8.6% ( -17% - 0%)
OrHighNotMed 41.62 (3.5%) 38.18
(4.7%) -8.3% ( -15% - 0%)
OrHighNotHigh 16.08 (3.3%) 14.84
(4.4%) -7.7% ( -14% - 0%)
BrowseDayOfYearTaxoFacets 1.31 (2.1%) 1.21
(6.4%) -7.1% ( -15% - 1%)
BrowseDateTaxoFacets 1.31 (2.1%) 1.22
(6.5%) -7.0% ( -15% - 1%)
Prefix3 20.13 (7.2%) 18.74
(5.9%) -6.9% ( -18% - 6%)
OrNotHighHigh 23.22 (3.1%) 21.63
(3.9%) -6.9% ( -13% - 0%)
IntNRQ 7.33 (9.3%) 6.83
(11.2%) -6.8% ( -24% - 15%)
Fuzzy2 105.61 (1.7%) 98.65
(1.3%) -6.6% ( -9% - -3%)
Wildcard 56.59 (5.4%) 52.86
(4.3%) -6.6% ( -15% - 3%)
MedSpanNear 36.06 (4.0%) 33.88
(3.6%) -6.0% ( -13% - 1%)
HighSpanNear 35.40 (4.0%) 33.39
(3.8%) -5.7% ( -12% - 2%)
Fuzzy1 89.36 (1.6%) 84.28
(1.5%) -5.7% ( -8% - -2%)
OrHighMed 28.17 (9.8%) 26.66
(3.6%) -5.4% ( -17% - 8%)
OrHighHigh 17.94 (10.5%) 17.01
(3.7%) -5.2% ( -17% - 10%)
LowTerm 397.33 (2.4%) 377.12
(1.4%) -5.1% ( -8% - -1%)
OrNotHighMed 86.69 (2.1%) 82.75
(3.1%) -4.5% ( -9% - 0%)
HighPhrase 8.58 (7.2%) 8.19
(6.6%) -4.5% ( -17% - 10%)
LowSpanNear 42.81 (1.5%) 41.17
(1.6%) -3.8% ( -6% - 0%)
Respell 71.63 (1.3%) 69.17
(1.4%) -3.4% ( -6% - 0%)
BrowseMonthSSDVFacets 5.74 (11.1%) 5.55
(10.8%) -3.4% ( -22% - 20%)
AndHighHigh 33.22 (1.6%) 32.15
(1.5%) -3.2% ( -6% - 0%)
LowPhrase 43.46 (1.6%) 42.39
(1.4%) -2.5% ( -5% - 0%)
PKLookup 360.20 (2.1%) 352.10
(1.3%) -2.3% ( -5% - 1%)
MedPhrase 33.01 (3.9%) 32.56
(3.7%) -1.4% ( -8% - 6%)
AndHighLow 706.78 (2.4%) 706.29
(1.5%) -0.1% ( -3% - 3%)
HighTermMonthSort 40.02 (4.4%) 40.36
(4.9%) 0.9% ( -8% - 10%)
OrNotHighLow 585.09 (2.8%) 593.40
(1.8%) 1.4% ( -3% - 6%)
AndHighMed 111.84 (2.6%) 113.65
(1.5%) 1.6% ( -2% - 5%)
Mike McCandless
http://blog.mikemccandless.com
On Fri, Mar 10, 2017 at 1:18 PM, Uwe Schindler <uschindler at apache.org>
wrote:
> Hi,
>
> we just noticed this issue: https://bugs.openjdk.java.net/
> browse/JDK-8176513
>
> As Apache Lucene relies heavily on performance of ByteBuffers (especially
> MappedByteBuffer), this would be a desaster if it would get even slower
> than Java 8. We were so happy that there was much work going on to improve
> the performance of ByteBuffers so they were at some point almost as fast as
> byte[]. Because of that we are currently working on making Lucene work fine
> with Java 9, because once it is out, we would inform all users and
> recommend to use Java 9 because of these optimizations. The tests of Lucene
> are already running perfectly, no problems like data corrumption (remember
> Java 7 GA or 7u40). Also Apache Solr people try to fix the remaining
> Hadoop/Kerberos-Auth issues because of Jigsaw. We also have unmapping
> working using Unsafe::invokeCleaner, so we are prepared...
>
> I am not yet sure if this bug affects us, we have to run perf tests first.
> Nevertheless, this is our usage pattern:
> - we only read from ByteBuffers (MappedByteBuffer), never store anything
> (we use mmap to execute Lucene searches on the mapped index with often 10th
> sometimes also 100th of gigabytes of data files that were mmapped).
> - we do sequential reads (position() and then getByte(), getXxX)
> - we also do positional reads like this test (for the so called DocValues
> in Lucene, which is a column based store). This is mainly like sorting
> search results based on a compare function that accesses a ByteBuffer as
> random-access source for comparison values.
> - we don't use IntBuffer, we work directly on ByteBuffer
>
> I asked Mike McCandless to run the performance tests with a recent Java 9
> version to see if it affects us. Is there any information, when this bug
> was introduced into Java 9? Nevertheless, please fix it for Java 9 GA, if
> it affects us it would be a major loss of search performance for us!
>
> It would be good to get some information about your plans :-) Thanks!
>
> Uwe
>
> -----
> Uwe Schindler
> uschindler at apache.org
> ASF Member, Apache Lucene PMC / Committer
> Bremen, Germany
> http://lucene.apache.org/
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe at lucene.apache.org
> For additional commands, e-mail: dev-help at lucene.apache.org
>
>
More information about the hotspot-dev
mailing list