On Tue, 9 Feb 2021 21:10:18 GMT, Claes Redestad <redes...@openjdk.org> wrote:
>> src/jdk.charsets/share/classes/sun/nio/cs/ext/ISO2022.java line 64: >> >>> 62: >>> 63: protected final byte maximumDesignatorLength = 4; >>> 64: >> >> This implementation moved to KR concrete implementation class. IIUC, this is >> the default impl for generic ISO2022 spec, so I believe the code being here >> is more reasonable. Any performance gain by moving this to KR specific class? > > The KR concrete impl is the only instantiation of this default impl - all > other were already implementing specialized `Decoders` that does not inherit > from `ISO2022.Decoder`, which is actually rather inefficient. The concrete KR > class uses a `DoubleByte.Decoder` that can now be created statically and used > directly in the `decode` method - bypassing the `tmpDecoder` indirection and > using tiny array+buffers which added quite a bit of overhead. So the > performance gain here was significant, and is the explanation `ISO2022_KR` is > now significantly ahead of the baseline on the `StringDecode` micro. OK. I don't think any more new ISO2022 charset would be added, so personally I still prefer the default impl in the ISO2022 itself, but I am ok with the code, as it improves the performance. Would you please add a comment explaining it? ------------- PR: https://git.openjdk.java.net/jdk/pull/2480
