Hi Claes,
Early in the design there was a question about whether the coder was in
the array
or the String. That probably translated into following the general pattern
that the UTF16 coding was nearly identical and parallel to Latin1
with minimal differences for the size of the data.
$.02, Roger
On 12/07/2018 02:35 PM, Claes Redestad wrote:
This is an interesting point: can anyone explain why there are two
distinct methods for LATIN1 and UTF16 equality, with corresponding
intrinsics? Aleksey? Tobias?
Testing with Arrays.equals then performance profile is
quite different due vectorization (often better, sometimes worse),
but this is performance-neutral for a variety of latin1 and utf16 inputs:
if (coder() == aString.coder())
return StringLatin1.equals(value, aString.value);
Is there some UTF16 input where StringLatin1.equals !=
StringUTF16.equals that forbids the above? Performance-wise it seems
neutral, and all tests seem to pass with the above (obviously need to
run more tests...).
Thanks!
/Claes
On 2018-12-07 04:53, James Laskey wrote:
Or simply;
if (anObject instanceof String) {
String aString = (String)anObject;
if (coder() == aString.coder())
return Arrays.equals(value, aString.value);
}
}
Sent from my iPhone
