RFR: 4926314: Optimize Reader.read(CharBuffer)

[Philippe Marschall]

On 17.01.21 18:48, Philippe Marschall wrote:
> ...
>
> To be honest backing out of the StreamDecoder changes looks like a good
> comprise to me to reduce the risk while still improving throughput and
> reducing allocation rate, especially in the on-heap path.

I gave it some more thought and propose to back out of the StreamDecoder
changes. While that leaves some optimization potential unused it keeps
the patch smaller, the risk lower and avoids any throughput regressions.

> Looking a bit further I wonder if CharArrayReader and StringReader
> should implement #read(CharBuffer) as well and call CharBuffer#put
> directly. And maybe even #transferTo(Writer).

I did have a look at this [1] for coders LATIN1(0) and UTF16(1) as well
as 128 and 1024 char sized readers for both on- and off-heap buffers.

CharArrayReader#read(CharBuffer)

on-heap
Higher throughput than master but slightly lower throughput than the
current PR. I don´ t know why that is, maybe the additional checks in
CharBuffer show up here.

off-heap
Higher throughput than master or the PR, all intermediate allocation is
gone.

StringReader#read(CharBuffer)

on-heap
Higher throughput than master but slightly lower throughput than the
current PR. I don´ t know why that is, maybe the additional checks in
CharBuffer show up here. The situation is similar to CharArrayReader.


off-heap
Lower throughput but all intermediate allocation is gone. What shows up
here is the lack of an optimized #put(String) method for off-heap
CharBuffers like was done in JDK-8011135 for on-heap buffers.

Based on this is propose to add CharArrayReader#read(CharBuffer),
assuming it is still in the scope of the bug. I wouldn't add
StringReader#read(CharBuffer) due to the throughput regression. I think
#transferTo(Writer) would be out of the scope of the bug. Is that ok?

  [1]
https://github.com/marschall/reader-benchmarks/blob/master/src/main/java/com/github/marschall/readerbenchmarks/CharsequenceReaderBenchmarks.java

Cheers
Philippe