Mike, I can certainly try to do that. Given how trivial the change is and the somewhat obvious observation that Long.parseLong would avoid boxing compared to Long.decode, I was simply pointing out a fairly easy change that could be made in case the maintainers of this class simply haven't looked at optimizing this method a bit. Obviously touching working code shouldn't be taken lightly, but do you see any issues with using Long.parseLong?
Thanks Sent from my phone On Feb 28, 2012 1:32 PM, "Mike Duigou" <[email protected]> wrote: > The easiest wat to proceed would be for you to submit a webrev patch with > both changes along with your microbenchmark test. Once the change is > incorporated in the jdk8 mainline the sustaining teams can evaluate it for > backporting to jdk 7 and 6. > > Mike > > On Feb 28 2012, at 06:26 , Vitaly Davidovich wrote: > > > Hi all, > > > > I noticed that this method could be made a bit more performant by: > > > > 1) creating a statically initialized Pattern for "-" and then calling > > split() on that. Currently the method calls name.split() which compiles > > the pattern on each invocation. > > > > 2) use Long.parseLong() instead of Long.decode() to extract the bits. > > > > With these changes, the method runs at least 20% faster (some runs were > > significantly faster) on an Intel Westmere server and should be a bit > more > > GC friendly. > > > > Any thoughts? I can send the full code a bit later when I'm in front of > my > > computer. > > > > Thanks > > > > Sent from my phone > >
