Right, I can't really explain why, but the effect is very visible and
reproducible in microbenchmarks. Differences in generated ASM might
be indicating that the inlining behavior changes enough to shift the
result around; maybe a job for @ForceInline?

I'll experiment and analyze a bit more tomorrow to see if I can find a
good explanation for the observed difference and/or a solution that
allows us to slim down the lookup array.

/Claes

On 2018-01-29 20:38, Paul Sandoz wrote:
Smaller in only the upper bound? I would an explicit upper bounds check would dominate that of the bounds check for the array itself.

Paul.

On Jan 29, 2018, at 11:37 AM, Claes Redestad <claes.redes...@oracle.com <mailto:claes.redes...@oracle.com>> wrote:

I ran with a smaller byte[] initially and saw about a 10% improvement from removing the branch, which is why I felt the superfluous bytes were motivated.

/Claes

Paul Sandoz <paul.san...@oracle.com <mailto:paul.san...@oracle.com>> skrev: (29 januari 2018 19:14:44 CET)


        On Jan 29, 2018, at 9:44 AM, Martin Buchholz
        <marti...@google.com <mailto:marti...@google.com>> wrote:
        Thanks. I might try to shrink the size of the static array,
        by only storing values between '0' and 'z', at the cost of
slightly greater lookup costs for each char.

    I was wondering the same, or just clip the end of the array to’z'

    if (ch <= ‘z’ && radix …) { // Might even fold the upper bounds check for 
DIGITS
       value = DIGITS[ch];
       ...
    }

    Paul.

        On Mon, Jan 29, 2018 at 3:15 AM, Claes Redestad
        <claes.redes...@oracle.com
        <mailto:claes.redes...@oracle.com>> wrote:

            Hi, for the latin1 block of CharacterData we can improve
            the digit(int, int) implementation by providing an
            optimized lookup table. This improves microbenchmarks
            exercising Integer.parseInt, Long.parseLong and
            UUID.fromString etc by around 50%for typical inputs.
            Webrev:
            http://cr.openjdk.java.net/~redestad/8196331/open.00/
            <http://cr.openjdk.java.net/%7Eredestad/8196331/open.00/>
            Bug: https://bugs.openjdk.java.net/browse/JDK-8196331 The
            lookup array is pre-calculated to minimize startup impact
(adds 1,027 bytecodes executed during initialization) /Claes


--
Sent from my Android device with K-9 Mail. Please excuse my brevity.


Reply via email to