RFR: 8205592: BigDecimal.doubleValue() is depressingly slow

Joe Darcy darcy at openjdk.org
Wed Apr 26 01:55:54 UTC 2023


On Thu, 7 Jul 2022 15:20:32 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

> A reimplementation of `BigDecimal.[double|float]Value()` to enhance performance, avoiding an intermediate string and its subsequent parsing on the slow path.

src/java.base/share/classes/java/math/BigDecimal.java line 308:

> 306:     /*
> 307:      * Let l = log_2(10).
> 308:      * Then, L < l < L + ulp(L) / 2, that is, L = roundTiesToEven(l).

It doesn't matter in terms of the code, but shouldn't this be something like:

L - (ulp(L)) < l < L  ulp(L)

In other words, without further checking, it isn't clear that L is the lower-bound of the two double value bracketing l.

(If the ulp function being discussed were the real-valued version than L +/- ulp(l) would also be a reasonable formulation.)

src/java.base/share/classes/java/math/BigDecimal.java line 3749:

> 3747:      */
> 3748:     @Override
> 3749:     public float floatValue() {

If the total size of code were a concern, I wouldn't be adverse to floatValue() being implemented as

return (float)doubleValue();

Given the 2p+2 property between the float and double formats, BigDecimal -> double -> float and BigDecimal -> float round the same way.

src/java.base/share/classes/java/math/BigDecimal.java line 3777:

> 3775:             return 0.0f;
> 3776:         }
> 3777:         BigInteger d = unscaledValue().abs();

I'd prefer a name other than "d" be used for the BigInteger significand's magnitude.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/9410#discussion_r1177225652
PR Review Comment: https://git.openjdk.org/jdk/pull/9410#discussion_r1177230119
PR Review Comment: https://git.openjdk.org/jdk/pull/9410#discussion_r1177228393


More information about the core-libs-dev mailing list