<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