On Mon, 20 Feb 2023 14:45:09 GMT, Eirik Bjorsnos <[email protected]> wrote:
>> This PR suggests we can speed up `StringLatin1.regionMatchesCI` by applying
>> 'the oldest ASCII trick in the book'.
>>
>> The new static method `CharacterDataLatin1.equalsIgnoreCase` compares two
>> latin1 bytes for equality ignoring case. `StringLatin1.regionMatchesCI` is
>> updated to use `equalsIgnoreCase`
>>
>> To verify the correctness of `equalsIgnoreCase`, a new test is added to
>> `EqualsIgnoreCase` with an exhaustive verification that all 256x256 latin1
>> code point pairs have an `equalsIgnoreCase` consistent with
>> Character.toUpperCase, Character.toLowerCase.
>>
>> Performance is tested for matching and mismatching cases of code point pairs
>> picked from the ASCII letter, ASCII number and latin1 letter ranges. Results
>> in the first comment below.
>
> Eirik Bjorsnos has updated the pull request incrementally with two additional
> commits since the last revision:
>
> - Add @bug tag to EqualsIgnoreCase test for correct issue JDK-8302871
> - Add @bug tag to EqualsIgnoreCase test for JDK-8302877
src/java.base/share/classes/java/lang/CharacterDataLatin1.java.template line
170:
> 168: * @return true if the two bytes are considered equals ignoring case
> in latin1
> 169: */
> 170: static boolean equalsIgnoreCase(byte b1, byte b2) {
Perhaps put this in `CharacterDataLatin1`, keeping it close to
toLowerCase/toUpperCase that you're changing to use similar logic with #12623
If you apply #12623 first - how much difference does this make on the micro
you're adding with this PR?
-------------
PR: https://git.openjdk.org/jdk/pull/12632
