<i18n dev> RFR: 8304245: Speed up CharacterData.of by avoiding bit shifting in the latin1 fast-path test [v2]
Eirik Bjorsnos
duke at openjdk.org
Wed Mar 15 15:13:24 UTC 2023
On Wed, 15 Mar 2023 14:57:43 GMT, Quan Anh Mai <qamai at openjdk.org> wrote:
>>> The StringLatin1.canEncode regression disappears.
>>
>> I mixed things up so StringLatin1.canEncode was benchmarked without the updated code.
>>
>> Here are updated benchmark results:
>>
>>
>> Baseline:
>>
>>
>> Benchmark (codePoint) Mode Cnt Score Error Units
>> Characters.isDigitRandom 1632 avgt 15 5.437 ± 0.235 ns/op
>>
>>
>> PR:
>>
>>
>> Benchmark (codePoint) Mode Cnt Score Error Units
>> Characters.isDigitRandom 1632 avgt 15 5.319 ± 0.341 ns/op
>>
>>
>> StringLatin1.canEncode:
>>
>>
>> Benchmark (codePoint) Mode Cnt Score Error Units
>> Characters.isDigitRandom 1632 avgt 15 5.447 ± 0.304 ns/op
>> ```
>>
>> So it seems using StringLatin1.canEncode still might have a regression also in the randomized input case.
>>
>> For this PR, I suggest we update StringLatin1.canEncode to be in sync with CharacterData.of, without one calling the other. If anyone wants to investigate the regression further, than can be done outside this PR.
>>
>> I have independently verified that StringLatin1.canEncode sees performance improvements using the StringIndexOf benchmark.
>
> We can do `Integer.compareUnsigned(ch, 0xFF) <= 0`
We could, but benchmarks show no performance improvements over the current PR. I think the current code is perhaps slightly more readable.
-------------
PR: https://git.openjdk.org/jdk/pull/13040
More information about the i18n-dev
mailing list