On Sat, 2 Dec 2023 16:56:22 GMT, Francesco Nigro <[email protected]> wrote:
> This improvement has been found on > https://github.com/vert-x3/vertx-web/pull/2526. > > It can potentially affect the existing ArraysSupport.mismatch caller > code-path performance ie requires investigation. src/java.base/share/classes/java/lang/String.java line 2184: > 2182: byte[] tv = value; > 2183: byte[] ov = other.value; > 2184: if (coder == otherCoder) { Is this change needed as `otherCoder` is not reused? Suggestion: byte[] tv = value; byte[] ov = other.value; byte coder = coder(); if (coder == other.coder()) { src/java.base/share/classes/java/lang/String.java line 2186: > 2184: if (coder == otherCoder) { > 2185: if (ooffset == 0 && toffset == 0 && len == (tv.length >> > coder) && ov.length == tv.length) { > 2186: return StringLatin1.equals(tv, ov); A few questions on this: - Should this also handle `UTF-16`? - Could we save a comparison by `OR`ing offsets? - The `equals` method will do the `tv` and `ov` length comparisons themselves, could we remove that check here or is the method call overhead too large? - Do you happen to have results for `make test TEST="micro:java.lang.StringComparisons"`? Suggestion: if ((ooffset | toffset) == 0 && len == (tv.length >> coder)) { return coder == LATIN1 ? StringLatin1.equals(tv, ov) : StringUTF16.equals(tv, ov); } ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16933#discussion_r1412902721 PR Review Comment: https://git.openjdk.org/jdk/pull/16933#discussion_r1412887365
