Francesco Nigro (@forked_franz) reports an issue where performance of String(byte[], int, int) constructors perform worse than String(char[], int, int) constructors for ASCII inputs, as tested on JDK 11.

The older System.arraycopy intrinsics may play a role here, e.g., do more bounds checking than the purpose-built intrinsic used for char[] compression. Failure to omit zeroing might also play a role.

Original benchmark: https://gist.github.com/franz1981/bf67ed8f328ed112a524c1150833c718

Gist of reported results, JDK 11 linux-x64: https://gist.github.com/franz1981/a2ba8a569b8a15903c90a46db988a10e

The pattern persists on mainline and also shows up on aarch64 - albeit less pronounced (StringCharCopy roughly 20% faster than StringByteCopy on my MacBook M1)

Attached an adjusted version of Francesco's AsciiCopy micro that focuses on the String copying and allows for testing larger inputs. In this particular microbenchmark the performance skew appears to persist on larger inputs.

I also included String(byte[], int, int, ISO_8859_1) which disappointingly lags slightly behind the deprecated String(byte[], int, int, int).

Numbers on my x86 AVX2 enabled workstation:

Benchmark (end) (start) Mode Cnt Score Error Units
AsciiCopy.asciiStringBytesCharsetCopy 9 1 avgt 10 18.955 ± 2.749 ns/op
AsciiCopy.asciiStringBytesCharsetCopy 17 1 avgt 10 20.029 ± 3.270 ns/op
AsciiCopy.asciiStringBytesCopy 9 1 avgt 10 15.253 ± 1.595 ns/op
AsciiCopy.asciiStringBytesCopy 17 1 avgt 10 17.346 ± 2.546 ns/op
AsciiCopy.asciiStringCharCopy 9 1 avgt 10 11.919 ± 0.328 ns/op
AsciiCopy.asciiStringCharCopy 17 1 avgt 10 17.374 ± 3.365 ns/op