RFR: 8358533: Improve performance of java.io.Reader.readAllLines [v3]

[Brian Burkhalter]

On Fri, 20 Jun 2025 17:16:58 GMT, Xueming Shen <sherman at openjdk.org> wrote:

>> The change is motivated by performance, but there will be many inputs that are less than the transfer buffer size and those will not use the StringBuilder, so creating it before it is needed could be avoided.
>> When a partial line is left in the transfer buffer, copy it to the beginning of the buffer and read more characters for the remaining size of the buffer. It would save some copying into and out of the SB. 
>> You might still need a fallback for really long lines (> transfer buffer size), but that might be more easily handled by reallocating the transfer buffer to make it larger.
>
> resizing/newCapacity is always expensive and tricky, string builder included. so maybe we should decide if 'long lines' (> transfer buffer size) is the goal of this pr.  if not, it might be reasonable/make sense (???) to simply go with "string" + the built-in string concatenation -> we don't care the scenario that most of the 'lines' > buffer.size.  i do agree we probably want to avoid paying the cost of copying in & out of the sb, but tweaking the transfer buffer resizing might also be tricky and potentially out of the scope as well. yes, it's always a trade off.

> My suggestion is to call `new StringBuilder(0)`

So changed in 8ccfd54.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25863#discussion_r2164684772