JDK 7u-dev review request 8024356: Double.parseDouble() is slow for long Strings

[Dmitry Nadezhin]

I agree with 1100 for this review (JDK7).

I think that we shouldn't change from 1100 to 768 in JDK8 because this is a
small performance enhancement.
This will save time for fixing other bugs.

The performance enhancement could be smarter if we replace constant
MAX_NDIGIT by some piece-linear function
function maxNDigit(decExponent). See:
http://cr.openjdk.java.net/~bpb/nDigits/java/double.pdf
I'd like to postpone this to JDK9 .


On Sat, Sep 14, 2013 at 4:39 AM, Brian Burkhalter <
brian.burkhalter at oracle.com> wrote:

> I would suggest leaving it at 1100 for this review (JDK7) and to 768
> (0x003) in JDK8. The latter will require another issue to be filed.
>
> On Sep 12, 2013, at 9:25 PM, Dmitry Nadezhin wrote:
>
> > For me, it is the only consideration.
> > I'm sure in 768 because I proved it formally using ACL2 tool.
> >
> >
> > On Fri, Sep 13, 2013 at 7:45 AM, David M. Lloyd <david.lloyd at redhat.com
> >wrote:
> >
> >> If that's the only consideration then just use 0x300 instead, which is
> >> easier to read *and* makes more sense anyway, in the context of the
> test.
> >>
> >>
> >> On 09/12/2013 10:13 PM, Dmitry Nadezhin wrote:
> >>
> >>> Should we change conservative constant 1100 to optimal constant 768 ?
> >>> My opinion is no (in JDK7), because the constant 1100 has lower cost of
> >>> review.
> >>> I mean that chances that a reviewer approves 1100 are higher than
> chances
> >>> that [s]he approves 768.
>