If BigDecimal is the Answer, it Must Have Been a Strange Question

Peter Lawrey

Jul. 07, 14 · Interview

Like (2)

Save

19.64K Views

Many developers have determined that BigDecimal is the only way to deal with money. Often they site that by replacing double with BigDecimal, they fixed a bug or ten. What I find unconvincing about this is that perhaps they could have fixed the bug in the handling of double and that the extra overhead of using BigDecimal.

My comparison, when asked to improve the performance of a financial application, I know at some time we will be removing BigDecimal if it is there. (It is usually not the biggest source of delays, but as we fix the system it moves up to the worst offender)

BigDecimal is not an improvement

BigDecimal has many problems, so take your pick, but an ugly syntax is perhaps the worst sin.

BigDecimal syntax is an unnatural.
BigDecimal uses more memory
BigDecimal creates garbage
BigDecimal is much slower for most operations (there are exceptions)

The following JMH benchmark demonstrates two problems with BigDecimal, clarity and performance.

The core code takes an average of two values.

The double implementation looks like this. Note: the need to use rounding.

mp[i] = round6((ap[i] + bp[i]) / 2);

The same operation using BigDecimal is not only long, but there is lots of boiler plate code to navigate

mp2[i] = ap2[i].add(bp2[i])
     .divide(BigDecimal.valueOf(2), 6, BigDecimal.ROUND_HALF_UP);

Does this give you different results? double has 15 digits of accuracy and the numbers are far less than 15 digits. If these prices had 17 digits, this would work, but nor work the poor human who have to also comprehend the price (i.e. they will never get incredibly long)

Performance

If you have to incurr coding overhead, usually this is done for performance reasons, but this doesn't make sense here.

Benchmark Mode Samples Score Score error Units

o.s.MyBenchmark.bigDecimalMidPrice thrpt 20 23638.568 590.094 ops/s

o.s.MyBenchmark.doubleMidPrice thrpt 20 123208.083 2109.738 ops/s

Conclusion

If you don't know how to use round in double, or your project mandates BigDecimal, then use BigDecimal. But if you have choice, don't just assume that BigDecimal is the right way to go.

The code

import org.openjdk.jmh.annotations.Benchmark;
import org.openjdk.jmh.annotations.Scope;
import org.openjdk.jmh.annotations.State;
import org.openjdk.jmh.runner.Runner;
import org.openjdk.jmh.runner.RunnerException;
import org.openjdk.jmh.runner.options.Options;
import org.openjdk.jmh.runner.options.OptionsBuilder;
import java.math.BigDecimal;
import java.util.Random;
@State(Scope.Thread)
public class MyBenchmark {
    static final int SIZE = 1024;
    final double[] ap = new double[SIZE];
    final double[] bp = new double[SIZE];
    final double[] mp = new double[SIZE];
    final BigDecimal[] ap2 = new BigDecimal[SIZE];
    final BigDecimal[] bp2 = new BigDecimal[SIZE];
    final BigDecimal[] mp2 = new BigDecimal[SIZE];
    public MyBenchmark() {
        Random rand = new Random(1);
        for (int i = 0; i < SIZE; i++) {
            int x = rand.nextInt(200000), y = rand.nextInt(10000);
            ap2[i] = BigDecimal.valueOf(ap[i] = x / 1e5);
            bp2[i] = BigDecimal.valueOf(bp[i] = (x + y) / 1e5);
        }
        doubleMidPrice();
        bigDecimalMidPrice();
        for (int i = 0; i < SIZE; i++) {
            if (mp[i] != mp2[i].doubleValue())
                throw new AssertionError(mp[i] + " " + mp2[i]);
        }
    }
    @Benchmark
    public void doubleMidPrice() {
        for (int i = 0; i < SIZE; i++)
            mp[i] = round6((ap[i] + bp[i]) / 2);
    }
    static double round6(double x) {
        final double factor = 1e6;
        return (long) (x * factor + 0.5) / factor;
    }
    @Benchmark
    public void bigDecimalMidPrice() {
        for (int i = 0; i < SIZE; i++)
            mp2[i] = ap2[i].add(bp2[i])
            .divide(BigDecimal.valueOf(2), 6, BigDecimal.ROUND_HALF_UP);
    }
    public static void main(String[] args) throws RunnerException {
        Options opt = new OptionsBuilder()
                .include(".*" + MyBenchmark.class.getSimpleName() + ".*")
                .forks(1)
                .build();
        new Runner(opt).run();
    }
}

Overhead (computing) Syntax (programming languages) application Comparison (grammar) Memory (storage engine) Garbage (computer science) Implementation

Published at DZone with permission of Peter Lawrey, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

Comments

If BigDecimal is the Answer, it Must Have Been a Strange Question

BigDecimal is not an improvement

Performance

Conclusion

The code

Popular on DZone

Partner Resources