On Tue, 10 Oct 2023 08:07:37 GMT, Chen Liang <li...@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
