On Fri, 15 Jan 2021 20:14:48 GMT, Roger Riggs <rri...@openjdk.org> wrote:
>> Since we're calculating two final values, that split was what necessitated a
>> `Result` object. Until valhalla I don't think there's a way to get rid of
>> the performance cost here without putting the bulk of the logic into the
>> constructor.
>>
>> Refactoring out some of the logic to utility methods could be a performance
>> neutral way to cut down the complexity, though. E.g.:
>> char c = (char)((b1 << 12) ^
>> (b2 << 6) ^
>> (b3 ^
>> (((byte) 0xE0 << 12) ^
>> ((byte) 0x80 << 6) ^
>> ((byte) 0x80 << 0))));
>> if (Character.isSurrogate(c)) {
>> putChar(dst, dp++, REPL);
>> } else {
>> putChar(dst, dp++, c);
>> }
>> could be reasonably factored out and reduced to something like:
>> putChar(dst, dp++, StringCoding.decode3(b1,
>> b2, b3));
>> I've refrained from refurbishing too much, though.
>
> I don't think you need to inline quite so much. Once the determination has
> been made about whether the result is Latin1 or UTF16 it calls separate
> methods anyway. For example, after calling hasNegatives() it is known what
> coding is needed.
> Then call out to a method returns the byte array.
(Also, every email is very long because it includes the performance data; next
time please put the performance data in a separate comment, not the PR).
-------------
PR: https://git.openjdk.java.net/jdk/pull/2102
