On Tue, 10 Oct 2023 10:22:18 GMT, Chen Liang <li...@openjdk.org> wrote:
>> 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.
>
> You are right, JIT profiles are based on bytecode, and by not sharing the
> code path with generic-radix parseInt, JIT can better optimize the base-10
> path.
>
> In addition, is `(digit = value[i++] - '0') >= 0 && digit <= 9` slower than a
> table lookup? Don't think you actually need that digit table.
-Benchmark (size) Mode Cnt Score Error Units (baseline)
-Integers.parseInt 500 avgt 15 2.474 ? 0.014 us/op
+Benchmark (size) Mode Cnt Score Error Units (non-lookup table)
+Integers.parseInt 500 avgt 15 2.376 ? 0.018 us/op
+Benchmark (size) Mode Cnt Score Error Units (current f6828ff)
+Integers.parseInt 500 avgt 15 2.267 ? 0.011 us/op
(digit = value[i++] - '0') >= 0 && digit <= 9 slower than a table lookup
(current version f6828ff), but faster than base line
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/16112#discussion_r1352837006
