OK! A surprising increase in code size. Thanks for checking. Paul.
> On Jan 30, 2018, at 2:40 AM, Claes Redestad <claes.redes...@oracle.com> wrote: > > The ASM is harder than usual to follow and compare since everything is > inlined aggressively, but it seems that since CharacterDataLatin1 is only > invoked for 0 <= ch < 256 (invariant established in CharacterData.of(int ch)) > then the compiler is able to elide bounds check entirely when the byte[] is > also 256 elements. > > Shrinking the array adds more branches and grows the compiled code size > for UUID.fromString from 751 to 1341 bytes, so it seems that even from a > footprint perspective then keeping the array at 256 elements is a win. :-) > > /Claes > > On 2018-01-29 22:04, Claes Redestad wrote: >> 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. >>> >> >
