On Sat, 19 Aug 2023 20:57:27 GMT, Glavo <[email protected]> wrote: > I mainly made these optimizations: > > * Avoid allocating `StringBuilder` when there are no characters in the URL > that need to be encoded; > * Implement a fast path for UTF-8. > > In addition to improving performance, these optimizations also reduce > temporary objects: > > * It no longer allocates any object when there are no characters in the URL > that need to be encoded; > * The initial size of StringBuilder is larger to avoid expansion as much as > possible; > * For UTF-8, the temporary `CharArrayWriter`, strings and byte arrays are no > longer needed. > > The results of the `URLEncodeDecode` benchmark: > > > Before: > Benchmark (count) (maxLength) (mySeed) Mode Cnt > Score Error Units > URLEncodeDecode.testEncodeUTF8 1024 1024 3 avgt 15 > 5.587 ? 0.010 ms/op > > After: > Benchmark (count) (maxLength) (mySeed) Mode Cnt > Score Error Units > URLEncodeDecode.testEncodeUTF8 1024 1024 3 avgt 15 > 3.582 ? 0.054 ms/op > > > I also updated the tests to add more test cases.
The fast path that just returns the given string if ASCII-only and no encoding looks simple enough. I don't particularly like the idea of embedding the logic of encoding UTF-8 into that class though, that increases the complexity significantly, and Charset encoders are there for that. Also I don't understand the reason for changing BitSet into a boolean array - that seems gratuitous? ------------- PR Comment: https://git.openjdk.org/jdk/pull/15354#issuecomment-1690474419
