RFR: 8314774: Optimize URLEncoder [v7]
Glavo
duke at openjdk.org
Thu Aug 24 10:24:29 UTC 2023
On Thu, 24 Aug 2023 10:17:01 GMT, Glavo <duke at openjdk.org> 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.
>
> Glavo has updated the pull request incrementally with one additional commit since the last revision:
>
> Update UTF8EncodeUtils
If the UTF-8 fast path is too complex for this PR, I will temporarily abandon this part of the changes and keep the general optimizations in this PR.
As far as encoding UTF-8 goes, I agree that this logic shouldn't be hardcoded in many places. I'm trying to extract this logic into a utility class ([UTF8EncodeUtils.java](https://github.com/openjdk/jdk/blob/08dc3a6ad69d50c62455d3e8823f548bb18e04a2/src/java.base/share/classes/jdk/internal/util/UTF8EncodeUtils.java)). Maybe it should be split into a separate PR?
-------------
PR Comment: https://git.openjdk.org/jdk/pull/15354#issuecomment-1691414850
More information about the net-dev
mailing list