On Fri, 1 Sep 2023 18:44:13 GMT, 温绍锦 <d...@openjdk.org> wrote: >> # Benchmark Result >> >> >> sh make/devkit/createJMHBundle.sh >> bash configure --with-jmh=build/jmh/jars >> make test TEST="micro:java.lang.StringUpperLower.*" >> >> >> >> ## 1. >> [aliyun_ecs_c8i.xlarge](https://help.aliyun.com/document_detail/25378.html#c8i) >> * cpu : intel xeon sapphire rapids (x64) >> >> ``` diff >> -Benchmark Mode Cnt Score Error Units (baseline) >> -StringUpperLower.lowerToLower avgt 15 27.180 ± 0.017 ns/op >> -StringUpperLower.lowerToUpper avgt 15 47.196 ± 0.066 ns/op >> -StringUpperLower.mixedToLower avgt 15 32.307 ± 0.072 ns/op >> -StringUpperLower.mixedToUpper avgt 15 44.005 ± 0.414 ns/op >> -StringUpperLower.upperToLower avgt 15 32.310 ± 0.033 ns/op >> -StringUpperLower.upperToUpper avgt 15 42.053 ± 0.341 ns/op >> >> +Benchmark Mode Cnt Score Error Units (Update 01) >> +StringUpperLower.lowerToLower avgt 15 16.964 ± 0.021 ns/op (+60.96%) >> +StringUpperLower.lowerToUpper avgt 15 46.491 ± 0.036 ns/op (+1.51%) >> +StringUpperLower.mixedToLower avgt 15 35.947 ± 0.254 ns/op (-10.12%) >> +StringUpperLower.mixedToUpper avgt 15 41.976 ± 0.326 ns/op (+4.83%) >> +StringUpperLower.upperToLower avgt 15 33.466 ± 4.036 ns/op (-3.45%) >> +StringUpperLower.upperToUpper avgt 15 17.446 ± 1.036 ns/op (+141.04%) >> >> +Benchmark Mode Cnt Score Error Units (Update 00) >> +StringUpperLower.lowerToLower avgt 15 16.976 ± 0.043 ns/op (+60.160) >> +StringUpperLower.lowerToUpper avgt 15 46.373 ± 0.086 ns/op (+1.77%) >> +StringUpperLower.mixedToLower avgt 15 32.018 ± 0.061 ns/op (+0.9%) >> +StringUpperLower.mixedToUpper avgt 15 42.019 ± 0.473 ns/op (+4.72%) >> +StringUpperLower.upperToLower avgt 15 32.052 ± 0.051 ns/op (+0.8%) >> +StringUpperLower.upperToUpper avgt 15 16.978 ± 0.190 ns/op (+147.69%) >> >> >> ## 2. >> [aliyun_ecs_c8a.xlarge](https://help.aliyun.com/document_detail/25378.html#c8a) >> * cpu : amd epc genoa (x64) >> >> ``` diff >> -Benchmark Mode Cnt Score Error Units (baseline) >> -StringUpperLower.lowerToLower avgt 15 22.164 ± 0.021 ns/op >> -StringUpperLower.lowerToUpper avgt 15 46.113 ± 0.047 ns/op >> -StringUpperLower.mixedToLower avgt 15 28.501 ± 0.037 ns/op >> -StringUpperLower.mixedToUpper avgt 15 38.782 ± 0.038 ns/op >> -StringUpperLower.upperToLower avgt 15 28.625 ± 0.162 ns/op >> -StringUpperLower.upperToUpper avgt 15 27.960 ± 0.038 ns/op >> >> +B... > > 温绍锦 has updated the pull request incrementally with one additional commit > since the last revision: > > use hex literal
The two odd codepoints I was curious about are `0xaa` and `0xba`, both of which are lower-case according to `Character.isLowerCase(..)` but does not actually have an uppercase. The Unicode data categorize these two as `Lo`, Letter, other, so I'm a little confused how they got tagged as lowercase. `Character.toUpperCaseEx` is specified as adhering to the definition of the unicode data (unlike some legacy java character definition that might differ subtly) so perhaps it's reasonable to specify this newly invented `isLowerCaseEx` as strictly adhering to the unicode data in which case I think `0xaa` and `0xbb` should not be considered lower case. I am not a domain expert and would like someone like @naotoj to weigh in here. But either way we should think about how to specify this kind of method to keep it precise. Even if it's only internal code.. I suggested `hasUpperCase` (or maybe `hasUpperCaseEx`) as a way out of this particular conundrum, since it makes perfect sense to define a method named like that to be equivalent to `return cp != CharacterDataLatin1.instance.toUpperCaseEx(cp);` ------------- PR Comment: https://git.openjdk.org/jdk/pull/14751#issuecomment-1704294149
