On Mon, 15 Feb 2021 11:30:54 GMT, Claes Redestad <redes...@openjdk.org> wrote:
>> This patch exposes a couple of intrinsics used by String to speed up ASCII >> checking and byte[] -> char[] inflation, which can be used by latin1 and >> ASCII-compatible CharsetDecoders to speed up decoding operations. >> >> - Fast-path implemented for all standard charsets, with up to 10x >> performance improvements in microbenchmarks reading Strings from >> ByteArrayInputStream. >> - Cleanup of StreamDecoder/-Encoder with some minor improvements when >> interpreting >> - Reworked creation of JavaLangAccess to be safely published for >> CharsetDecoders/-Encoders used for setting up System.out/in. As JLA and >> these encoders are created during System.initPhase1 the current sequence >> caused the initialization to became unstable and a few tests were >> consistently getting an NPE. >> >> Testing: tier1-3 > > On the best-case microbenchmark (the byte stream is all ASCII), speed-ups are > quite telling: > > Before: > Benchmark (charsetName) (length) > Mode Cnt Score Error Units > ByteStreamDecoder.readStringReader US-ASCII 256 > avgt 10 2085.399 ± 66.522 ns/op > ByteStreamDecoder.readStringReader US-ASCII 4096 > avgt 10 12466.702 ± 747.116 ns/op > ByteStreamDecoder.readStringReader US-ASCII 25000 > avgt 10 123508.987 ± 3583.345 ns/op > ByteStreamDecoder.readStringReader ISO-8859-1 256 > avgt 10 1894.185 ± 51.772 ns/op > ByteStreamDecoder.readStringReader ISO-8859-1 4096 > avgt 10 8117.404 ± 594.708 ns/op > ByteStreamDecoder.readStringReader ISO-8859-1 25000 > avgt 10 99409.792 ± 28308.936 ns/op > ByteStreamDecoder.readStringReader UTF-8 256 > avgt 10 2090.337 ± 56.500 ns/op > ByteStreamDecoder.readStringReader UTF-8 4096 > avgt 10 11698.221 ± 898.910 ns/op > ByteStreamDecoder.readStringReader UTF-8 25000 > avgt 10 66568.987 ± 4204.361 ns/op > ByteStreamDecoder.readStringReader ISO-8859-6 256 > avgt 10 3061.130 ± 120.132 ns/op > ByteStreamDecoder.readStringReader ISO-8859-6 4096 > avgt 10 24623.494 ± 1916.362 ns/op > ByteStreamDecoder.readStringReader ISO-8859-6 25000 > avgt 10 139138.140 ± 7109.636 ns/op > ByteStreamDecoder.readStringReader MS932 256 > avgt 10 2612.535 ± 98.638 ns/op > ByteStreamDecoder.readStringReader MS932 4096 > avgt 10 18843.438 ± 1767.822 ns/op > ByteStreamDecoder.readStringReader MS932 25000 > avgt 10 119923.997 ± 18560.065 ns/op > > After: > Benchmark (charsetName) (length) > Mode Cnt Score Error Units > ByteStreamDecoder.readStringReader US-ASCII 256 > avgt 10 1556.588 ± 37.083 ns/op > ByteStreamDecoder.readStringReader US-ASCII 4096 > avgt 10 3290.627 ± 125.327 ns/op > ByteStreamDecoder.readStringReader US-ASCII 25000 > avgt 10 13118.794 ± 597.086 ns/op > ByteStreamDecoder.readStringReader ISO-8859-1 256 > avgt 10 1525.460 ± 36.510 ns/op > ByteStreamDecoder.readStringReader ISO-8859-1 4096 > avgt 10 3051.887 ± 113.036 ns/op > ByteStreamDecoder.readStringReader ISO-8859-1 25000 > avgt 10 11401.228 ± 563.124 ns/op > ByteStreamDecoder.readStringReader UTF-8 256 > avgt 10 1596.878 ± 43.824 ns/op > ByteStreamDecoder.readStringReader UTF-8 4096 > avgt 10 3349.961 ± 119.278 ns/op > ByteStreamDecoder.readStringReader UTF-8 25000 > avgt 10 13273.403 ± 591.600 ns/op > ByteStreamDecoder.readStringReader ISO-8859-6 256 > avgt 10 1602.328 ± 44.092 ns/op > ByteStreamDecoder.readStringReader ISO-8859-6 4096 > avgt 10 3403.312 ± 107.516 ns/op > ByteStreamDecoder.readStringReader ISO-8859-6 25000 > avgt 10 13163.468 ± 709.642 ns/op > ByteStreamDecoder.readStringReader MS932 256 > avgt 10 1602.837 ± 32.021 ns/op > ByteStreamDecoder.readStringReader MS932 4096 > avgt 10 3379.439 ± 87.716 ns/op > ByteStreamDecoder.readStringReader MS932 25000 > avgt 10 13376.980 ± 669.983 ns/op > > Performance degrades when you mix in non-ASCII characters, but so does the > `new String(byte[], Charset)` baseline. While there might be algorithmic > refinements possible to improve on some of the non-ASCII variants I'm happy > to leave that to a follow-up and keep this RFE reasonably straightforward. Is there a reason `sun.nio.cs.ISO_8859_1.Encoder#implEncodeISOArray(char[], int, byte[], int, int)` wasn't moved to `JavaLangAccess` as well? ------------- PR: https://git.openjdk.java.net/jdk/pull/2574
