Sweet. Just be aware that the floatValue() optimization requires Float.parseFloat to be fixed to match IEEE 754 behavior, as you're apparently doing with Double.parseDouble, to pass tests.
(The separate patch I sent in to fix that is probably invalidated by your changes, but it shouldn't be too difficult to do yourself -- it really is just copy/pasting the Double.parseDouble implementation and using updated constants.) On Thu, Feb 21, 2013 at 1:27 PM, Brian Burkhalter < brian.burkhal...@oracle.com> wrote: > My initial testing with another micro-benchmarking framework (other than > Caliper) shows a performance increase of >900X for doubleValue() and >1500X > for floatValue() on a MacBookPro5,3. > > There is some more evaluation yet to be done but we should be able to move > this patch along pretty soon. > > Brian > > On Feb 15, 2013, at 4:41 PM, Brian Burkhalter wrote: > > > Hi Louis, > > > > After the two issues for which I've posted review requests (6480539 - > stripTrailingZeros(), 4396272 - Parsing doubles fails to follow IEEE) are > resolved, issue 7131192 is currently very near the head of my queue. Given > that I still have a ways to go to get up to speed on this entire topic area > and code base, I would hesitate to give a date estimate just yet. > > > > Brian > > > >> Any update on when this could get reviewed? > >> > >> > >> On Thu, Dec 13, 2012 at 3:36 PM, Louis Wasserman <lowas...@google.com> > wrote: > >> Hi, > >> > >> I'm working at Google now, but I'd like to revive this patch as a > contribution from Google. At the moment, what's mainly needed is review > for http://bugs.sun.com/view_bug.do?bug_id=7192954, the fix to > Float.parseFloat's rounding behavior, before we can go anywhere with the > patch to optimize BigInteger.floatValue() and doubleValue(). > >> Would anyone be able to review that patch so these can start moving > forward? > >> > >> Thanks, > >> Louis Wasserman > >> Java Core Libraries Team @ Google > >> guava-libraries.googlecode.com > > -- Louis Wasserman
