On Fri, 2 May 2025 07:13:21 GMT, Shaojin Wen <s...@openjdk.org> wrote:
> > > ```java > > > > char[] ca = new char[end - off]; > > > ``` > > > Your code here has a memory allocation, which may cause slowdown > > > > This is exactly what I wanted to express with my posting. > > I agree with you that this PR can improve the performance of Reader's method > ` int read(char[] cbuf, int off, int len)`, but may not help the performance > of Reader::getChars. I have performed a JMH Benchmark to compare the code with and without the optimization, and the result is surprising: Benchmark | (SIZE) | Mode | Cnt | Score | | Error | Units 25 (modified) | 2 | thrpt | 25 | 71277668 | ± | 5549555 | ops/s 25 (modified) | 128 | thrpt | 25 | 33916527 | ± | 2631800 | ops/s 25 (modified) | 1024 | thrpt | 25 | 4291498 | ± | 401636 | ops/s 25 (modified) | 8192 | thrpt | 25 | 419871 | ± | 63557 | ops/s Benchmark | (SIZE) | Mode | Cnt | Score | | Error | Units 25 (original) | 2 | thrpt | 25 | 159882761 | ± | 2900397 | ops/s 25 (original) | 128 | thrpt | 25 | 24093787 | ± | 1706259 | ops/s 25 (original) | 1024 | thrpt | 25 | 3794393 | ± | 28097 | ops/s 25 (original) | 8192 | thrpt | 25 | 491340 | ± | 5569 | ops/s Actually for appended lengths of 128...1024 characters, the modified case is faster. This means, the benefit of `StringUTF16::compress` in fact outperforms the penalty implied by `new char[]`! While for size 1024 chars the benefit is rather small, for size 128 it is huge: More than 40% gain in throughput! 🚀 I will repeat the benchmark with more steps in the range 2...1024 to see where the break-even-point is, so we effectively can enable the optimization in a performance-wise "safe" range. Stay tuned! 😃 ------------- PR Comment: https://git.openjdk.org/jdk/pull/24773#issuecomment-2848689948
