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

[Raffaello Giulietti]

On Thu, 12 Oct 2023 08:58:18 GMT, Chen Liang <liach at openjdk.org> wrote:

>> While only optimizing the fast path is a good idea, I think it is important to make sure there is no regression on the slow path - as @schlosna pointed out, it's a common way to check if a string can be converted to an int.
>
> This patch should have little impact on exception-path performance. Remember String concatenation is done with StringBuilder in java.base, so changing formatter to that might have some performance difference. However, the main overhead of exception was from creation and initialization of stack trace.; the new code was just copies of the existing generic-radix parseInt, except it has a more efficient way to obtain digits via a table.

Let's not forget that `Character.digit()` has a pretty decent fast path for Latin1, including a 256 bytes lookup-table.

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

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