Hallo Mike,
thank you for the update! The comparison with NIOFSDirectory is helpful, as we can now conclude: * There is a minor slowdown implied by Java 9 in comparison to Java 8, which can have to do with other changed due to Jigsaw module system, and is not related to the ByteBuffer issue. As NIOFSDirectory does not really use ByteBuffers in a performance critical way (it is just used to read buffers of 8 or 16 KiB size from FileChannel into a HeapByteBuffer wrapped around a byte[] that is used for BufferedIndexInput), Andrew Haley’s investigation of byte buffer slowdowns cannot have any impact here. The ByteBuffer API is never used to access the byte[] contents, ByteBuffer is just used to pass the Lucene byte[] between FileChannel and our code! * NIOFSDirectory is still much slower for accessing the Lucene index than mmap (as expected, especially for sorting where positional reads are really needed), so the current Lucene default of using MMapDirectory of 64 bit platforms still outweights any other Lucene directory implementation. * As there is a larger slowdown if Lucene uses the MMapDirectory implementation on Java 9 in comparison to Java 8, we should really look into the issues! So Andrew Haley is right, there is some slowdown not only affecting HeapByteBuffers! Maybe it is caused by missing vectorization or because the code calling the ByteBuffers is much more complicated than Andrew’s tests, Hotspot is failing to properly optimize the access to DirectByteBuffer, too. Andrew & others, if you have a patch ready, we can try to benchmark it! Uwe From: Michael McCandless [mailto:luc...@mikemccandless.com] Sent: Monday, March 13, 2017 4:44 PM To: Uwe Schindler <uschind...@apache.org> Cc: Andrew Haley <a...@redhat.com>; Lucene/Solr dev <dev@lucene.apache.org>; jdk9-...@openjdk.java.net; hotspot-...@openjdk.java.net Subject: Re: ByteBuffer performance issue in Java 9? I reran the same test as before, this time using Lucene's NIOFSDirectory (java.nio's FileChannel for positional reads). There is still some slowdown, though a bit less than with MMapDirectory: Task QPS base StdDev QPS comp StdDev Pct diff LowSloppyPhrase 9.12 (5.2%) 7.89 (3.6%) -13.5% ( -21% - -4%) HighSloppyPhrase 6.25 (4.1%) 5.57 (3.3%) -10.8% ( -17% - -3%) MedSloppyPhrase 4.29 (3.8%) 3.85 (3.0%) -10.1% ( -16% - -3%) BrowseDayOfYearSSDVFacets 4.72 (8.8%) 4.32 (5.4%) -8.4% ( -20% - 6%) BrowseMonthTaxoFacets 1.31 (2.9%) 1.20 (4.7%) -8.3% ( -15% - 0%) BrowseDayOfYearTaxoFacets 1.17 (4.0%) 1.08 (4.1%) -7.7% ( -15% - 0%) BrowseDateTaxoFacets 1.18 (4.0%) 1.09 (4.1%) -7.6% ( -15% - 0%) BrowseMonthSSDVFacets 5.39 (4.3%) 4.98 (10.7%) -7.6% ( -21% - 7%) HighTerm 29.47 (5.3%) 27.45 (4.2%) -6.9% ( -15% - 2%) HighTermDayOfYearSort 14.24 (4.6%) 13.35 (5.5%) -6.3% ( -15% - 3%) MedTerm 44.47 (4.0%) 42.02 (3.4%) -5.5% ( -12% - 1%) OrHighNotLow 33.13 (5.0%) 31.39 (4.3%) -5.2% ( -13% - 4%) OrHighLow 26.84 (4.2%) 25.49 (4.0%) -5.0% ( -12% - 3%) HighPhrase 7.51 (5.4%) 7.17 (4.0%) -4.5% ( -13% - 5%) Fuzzy2 51.32 (0.9%) 49.03 (1.2%) -4.5% ( -6% - -2%) OrHighNotHigh 13.18 (3.5%) 12.64 (3.7%) -4.2% ( -10% - 3%) IntNRQ 6.28 (6.3%) 6.03 (9.9%) -4.0% ( -18% - 12%) OrHighNotMed 27.69 (2.9%) 26.65 (3.3%) -3.8% ( -9% - 2%) Fuzzy1 42.32 (0.8%) 40.88 (1.1%) -3.4% ( -5% - -1%) MedSpanNear 27.44 (2.4%) 26.57 (2.8%) -3.2% ( -8% - 2%) OrNotHighHigh 17.58 (2.8%) 17.04 (3.3%) -3.1% ( -8% - 3%) HighSpanNear 26.83 (2.2%) 26.03 (2.5%) -3.0% ( -7% - 1%) Respell 49.07 (1.2%) 47.62 (0.8%) -3.0% ( -4% - 0%) LowPhrase 31.19 (1.5%) 30.34 (1.2%) -2.7% ( -5% - 0%) Wildcard 51.30 (4.8%) 49.93 (4.3%) -2.7% ( -11% - 6%) LowSpanNear 31.05 (1.2%) 30.40 (1.5%) -2.1% ( -4% - 0%) LowTerm 105.83 (1.1%) 103.78 (1.4%) -1.9% ( -4% - 0%) OrNotHighMed 49.08 (1.8%) 48.16 (2.1%) -1.9% ( -5% - 2%) OrHighMed 18.44 (5.8%) 18.09 (5.1%) -1.9% ( -12% - 9%) AndHighHigh 21.22 (1.0%) 20.82 (1.3%) -1.9% ( -4% - 0%) HighTermMonthSort 32.01 (3.9%) 31.43 (5.3%) -1.8% ( -10% - 7%) OrHighHigh 12.89 (7.0%) 12.66 (6.0%) -1.8% ( -13% - 12%) MedPhrase 24.09 (2.3%) 23.80 (2.2%) -1.2% ( -5% - 3%) AndHighLow 447.74 (1.5%) 443.85 (1.7%) -0.9% ( -3% - 2%) Prefix3 18.41 (6.8%) 18.28 (5.6%) -0.7% ( -12% - 12%) OrNotHighLow 254.77 (1.4%) 254.59 (1.2%) -0.1% ( -2% - 2%) AndHighMed 63.15 (1.5%) 63.47 (0.9%) 0.5% ( -1% - 3%) PKLookup 347.80 (2.3%) 349.93 (2.1%) 0.6% ( -3% - 5%) Mike McCandless <http://blog.mikemccandless.com> http://blog.mikemccandless.com On Mon, Mar 13, 2017 at 10:16 AM, Michael McCandless < <mailto:luc...@mikemccandless.com> luc...@mikemccandless.com> wrote: Hi Uwe, OK, I'll test with NIOFSDirectory as well ... that's a good idea. I do remember testing earlier Java 9 builds long ago, but I can't remember what the outcome was. Mike McCandless <http://blog.mikemccandless.com> http://blog.mikemccandless.com On Mon, Mar 13, 2017 at 6:35 AM, Uwe Schindler < <mailto:uschind...@apache.org> uschind...@apache.org> wrote: Hi Andrew, yes that was my impression, too. Just for cross-checking: Mike, is it possible to also add a perf comparison between Java 8 and Java 9 when using SimpleFSDirectory or NIOFSDirectory (which are both FileChannel based since Java 7, the name is just backwards-compatibility)? If we see a slowdown there (maybe even larger) than it is not related to ByteBuffer positional/byte-wise reads and there is a general performance issue somewhere else. > Right, but ByteBuffers were significantly rewritten for a significant > performance *increase*. Any slowdown shows that something has gone > very wrong indeed. That would be a pity, because of that we should check the above case with non-mmap based, conventional index access. As far as I remember: at the time when you announced the bytebuffer improvements we did some performance measurements and were impressed by the speedup. I think Robert Muir did something. Mike, do you know? Maybe we should check with a Java 9 preview build from that time. I know that you can download older builds by changing the build number in the download URL. Uwe
