RFR: 8358533: Improve performance of java.io.Reader.readAllLines [v3]
Brian Burkhalter
bpb at openjdk.org
Tue Jun 24 19:03:28 UTC 2025
On Tue, 24 Jun 2025 18:49:08 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:
>> 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.
> 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.
The "transfer buffer" is the character array `cb`, right?
> 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.
The size of the array `cb` is not intended to be commensurate with line length, but rather to allow reading multiple lines thereby cutting down the nunber of reads.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/25863#discussion_r2164702082
More information about the core-libs-dev
mailing list