Content.Sink.write(sink, last, utf8Content, callback) could become faster

[gnikolaidis]

Jetty version(s)
Jetty 12.0.x

Enhancement Description
Looking at the source code, I see that the method body of Content.Sink.write(sink, last, utf8Content, callback) is using StandardCharsets.UTF_8.encode(utf8Content) to create the UTF-8 ByteBuffer.

I believe that ByteBuffer.wrap(utf8Content.getBytes(StandardCharsets.UTF_8)) would be quite faster, as in recent Java versions (which use UTF8 internally) it is implemented as a simple System.arrayCopy().

[lorban]

You are right, a quick JMH benchmark clearly shows that wrap/getBytes is consistenly faster than encoding:

Fully ASCII string
 JDK 22
  Utf8Benchmark.testEncode        thrpt   10   8642774.694 ± 194220.398  ops/s
  Utf8Benchmark.testWrapGetBytes  thrpt   10  52008364.510 ± 271773.779  ops/s
 JDK 17
  Utf8Benchmark.testEncode        thrpt   10   7355221.908 ± 396420.981  ops/s
  Utf8Benchmark.testWrapGetBytes  thrpt   10  52114741.560 ± 124515.129  ops/s

French string
 JDK 22
  Utf8Benchmark.testEncode        thrpt   10   4858458.628 ± 269877.435  ops/s
  Utf8Benchmark.testWrapGetBytes  thrpt   10  17264867.586 ± 227175.842  ops/s
 JDK 17
  Utf8Benchmark.testEncode        thrpt   10   4346969.813 ± 213333.374  ops/s
  Utf8Benchmark.testWrapGetBytes  thrpt   10  16451271.214 ± 125170.260  ops/s

Japanese string
 JDK 22
  Utf8Benchmark.testEncode        thrpt   10  2819575.012 ± 142874.446  ops/s
  Utf8Benchmark.testWrapGetBytes  thrpt   10  7802310.700 ±  74366.173  ops/s
 JDK 17
  Utf8Benchmark.testEncode        thrpt   10  2670866.437 ± 155794.533  ops/s
  Utf8Benchmark.testWrapGetBytes  thrpt   10  8240865.962 ±  70066.445  ops/s

so I'm going to create a pull request to submit this enhancement.

Thanks for the suggestion!

[joakime]

@lorban what's the GC difference like?

[lorban]

@joakime Interesting question. JMH's GCProfiler reports that the encode benchmark generates about 2 to 10 GB/s of garbage while wrap/getBytes generates about 25 GB/s... which is probably about the max memory bandwidth of my machine.

Still, GC'ing seems to be faster than encoding.

[sbordet]

How is this not a JDK bug?

[gnikolaidis]

My guess as to why it not a JDK bug is that Charset.encode(String) is very explicit that it must produce the same result as Charset.encode(CharBuffer), which in turn - quoting the Javadoc - always replaces malformed-input and unmappable-character sequences with charset's default replacement string - which may or may not be the case with JDK's UTF-8 encoding.

[gnikolaidis]

@joakime Interesting question. JMH's GCProfiler reports that the encode benchmark generates about 2 to 10 GB/s of garbage while wrap/getBytes generates about 25 GB/s... which is probably about the max memory bandwidth of my machine.

Still, GC'ing seems to be faster than encoding.

These results are probably just an artifact of the higher overall throughput.

[joakime]

My guess as to why it not a JDK bug is that Charset.encode(String) is very explicit that it must produce the same result as Charset.encode(CharBuffer), which in turn - quoting the Javadoc - always replaces malformed-input and unmappable-character sequences with charset's default replacement string - which may or may not be the case with JDK's UTF-8 encoding.

Error handling / Bad input handling is an important aspect of this.

@lorban what happens if the new technique encounters bad/malformed input?
Will it throw an exception? or will it replace characters with the UTF-8 replacement character?

[lorban]

@gnikolaidis I've modified my benchmark to make it more apparent that when the given string is purely ASCII, the wrap/getBytes throughput bottlenecks on memory bandwidth, so it's purely a memcopy/GC benchmark in that case. In all other cases, some encoding logic has to run and it's more complex to compare.

@joakime since the source is a String object, wouldn't the invalid bytes be returned as-is in the returned byte array?