RFR: 8317980: Optimization for Integer.parseInt and Long.parseLong

[Shaojin Wen]

On Tue, 10 Oct 2023 08:07:37 GMT, Chen Liang <liach at openjdk.org> wrote:

>> By extracting the code that creates the exception, the CodeSize of these methods is less than the default FreqInlineSize 325.  and for the scenario where the most commonly used radix is not specified and the String coder is LATIN1, fast-path can improves the performance 10% of parseInt(String)/parseLong(String).
>
> src/java.base/share/classes/java/lang/Integer.java line 682:
> 
>> 680:      */
>> 681:     public static int parseInt(String s) throws NumberFormatException {
>> 682:         if (s != null && s.coder() == String.LATIN1) {
> 
> Does this code block actually speed up `parseInt`? I recommend you remove this code block and test `parseInt` and `parseLong` again only with new NumberFormatException factories.

parseInt & parseLong are accelerated by this code, the key code is here

class DecimalDigits {
    public static int digit(byte ch) {
        return DIGITS_LATIN1[ch & 0xFF]; // If remove & 0xFF it won't get faster
    }
}


This optimization can only be done when radix is fixed.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16112#discussion_r1352076040