On Fri, 20 Jun 2025 17:16:58 GMT, Xueming Shen <sher...@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
