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
