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

[David M. Lloyd]

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.
>
>
>
> On Fri, Sep 13, 2013 at 12:49 AM, Brian Burkhalter <
> brian.burkhalter at oracle.com> wrote:
>
>> On Sep 12, 2013, at 1:00 PM, David Chase wrote:
>>
>> On 2013-09-12, at 1:17 AM, Dmitry Nadezhin <dmitry.nadezhin at gmail.com>
>> wrote:
>>
>> The optimal constant for double conversion could be 768 ,
>>
>> the optimal constant for float conversion could be 142,
>>
>> but I leave this optimization to JDK 9.
>>
>>
>> It would be helpful to mention in the proof/comment, that 768 refers to the
>> decimal representation that has had leading zeroes between decimal point
>> and mantissa trimmed.
>>
>>
>> I updated the webrev to include a comment for MAX_NDIGITS sans both
>> hyperlink and the foregoing verbiage:
>>
>> http://cr.openjdk.java.net/~bpb/8024356/
>>
>> If there is any more tweaking of comments which needs to be effected prior
>> to an approval request being posted to 7u-dev, please let me know.
>>
>> Thanks,
>>
>> Brian
>>


-- 
- DML