On Wed, 15 Mar 2023 14:57:43 GMT, Quan Anh Mai <qa...@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
