JDK 7u-dev review request 8024356: Double.parseDouble() is slow for long Strings
David M. Lloyd
david.lloyd at redhat.com
Fri Sep 13 03:45:57 UTC 2013
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
> 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>
>> 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:
>> 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.
More information about the core-libs-dev