Java BigDecimal strange performance behaviour

Question

Today I came cross a strange performance behaviour with BigDecimal. In a simple word, there is a significant difference between the following two pieces of code trying to do the same thing

int hash = foo();
BigDecimal number = new BigDecimal(hash);

vs

BigDecimal number = new BigDecimal(foo());

to prove it, I have the class below to show the difference. My java is 1.7.0_75-b13, 64 bit, mac. In my environment, the first loop took 2s, second loop took 5s.

import java.math.BigDecimal;

public class Crazy {

public static void main(String[] args) {
    new Crazy().run();
}

void run() {
    // init

    long count = 1000000000l;

    // start test 1

    long start = System.currentTimeMillis();

    long sum = 0;
    for (long i=0; i<count; i++) {
        sum = add(sum);
    }

    long end = System.currentTimeMillis();
    System.out.println(end - start);

    // start test 2

    long start2 = end;
    sum = 0;
    for (long i=0; i<count; i++) {
        sum = add1(sum);
    }

    long end2 = System.currentTimeMillis();
    System.out.println(end2 - start2);
}

long add(long sum) {
    int hash = hashCode();
    BigDecimal number = new BigDecimal(hash);
    sum += number.longValue();
    return sum;
}

long add1(long sum) {
    BigDecimal number = new BigDecimal(hashCode());
    sum += number.longValue();
    return sum;
}
}

javap output

long add(long);
Code:
   0: aload_0       
   1: invokevirtual #56                 // Method java/lang/Object.hashCode:()I
   4: istore_3      
   5: new           #60                 // class java/math/BigDecimal
   8: dup           
   9: iload_3       
  10: invokespecial #62                 // Method java/math/BigDecimal."<init>":(I)V
  13: astore        4
  15: lload_1       
  16: aload         4
  18: invokevirtual #65                 // Method java/math/BigDecimal.longValue:()J
  21: ladd          
  22: lstore_1      
  23: lload_1       
  24: lreturn       

long add1(long);
Code:
   0: new           #60                 // class java/math/BigDecimal
   3: dup           
   4: aload_0       
   5: invokevirtual #56                 // Method java/lang/Object.hashCode:()I
   8: invokespecial #62                 // Method java/math/BigDecimal."<init>":(I)V
  11: astore_3      
  12: lload_1       
  13: aload_3       
  14: invokevirtual #65                 // Method java/math/BigDecimal.longValue:()J
  17: ladd          
  18: lstore_1      
  19: lload_1       
  20: lreturn

Sounds like some "micro-benchmark" effect to me, both form are equivalent — , May 27 '15 at 06:11
Try change the order of `add()` and `add1()` in the code and see what happens? — ntalbs, May 27 '15 at 06:13
Also: don't use `System.currentTimeMillis()` to measure elapsed time. See Kevin Bourillion's answer on http://stackoverflow.com/questions/1770010/how-do-i-measure-time-elapsed-in-java — Andy Turner, May 27 '15 at 06:17
@ntalbs switching add() and add1() will make the 1st loop 5s and 2nd loop 2s — Water Guo, May 27 '15 at 06:17
@Andy point taken. but in this case, the difference is so big that i can even feel it — Water Guo, May 27 '15 at 06:19
Surely this test is performed badly, but I can confirm the effect on JDK 1.7.0.79 64bit using JMH 1.9. `add1` is actually slower. Gist is [here](https://gist.github.com/amaembo/110c4499398d66880a73). — Tagir Valeev, May 27 '15 at 06:29
@NitinDandriyal yes, it can be repeated as many times as you want. result is consistent. as for start2=end, plz forgive my laziness — Water Guo, May 27 '15 at 06:30

score 2 · Answer 1 · answered May 27 '15 at 06:43

I reproduced the effect on Java 1.7.0.79 using the following benchmark:

import java.math.BigDecimal;
import java.util.concurrent.TimeUnit;

import org.openjdk.jmh.infra.Blackhole;
import org.openjdk.jmh.annotations.*;

@Warmup(iterations = 5, time = 3, timeUnit = TimeUnit.SECONDS)
@Measurement(iterations = 10, time = 3, timeUnit = TimeUnit.SECONDS)
@BenchmarkMode(Mode.AverageTime)
@OutputTimeUnit(TimeUnit.MILLISECONDS)
@Fork(2)
@State(Scope.Benchmark)
public class AddTest {
    long add(long sum) {
        int hash = hashCode();
        BigDecimal number = new BigDecimal(hash);
        sum += number.longValue();
        return sum;
    }

    long add1(long sum) {
        BigDecimal number = new BigDecimal(hashCode());
        sum += number.longValue();
        return sum;
    }

    @Benchmark
    public void testAdd(Blackhole bh) {
        long count = 100000000l;
        long sum = 0;
        for (long i=0; i<count; i++) {
            sum = add(sum);
        }
        bh.consume(sum);
    }

    @Benchmark
    public void testAdd1(Blackhole bh) {
        long count = 100000000l;
        long sum = 0;
        for (long i=0; i<count; i++) {
            sum = add1(sum);
        }
        bh.consume(sum);
    }
}

The results are the following:

# JMH 1.9 (released 40 days ago)
# VM invoker: C:\Program Files\Java\jdk1.7.0_79\jre\bin\java.exe
# VM options: <none>

Benchmark         Mode  Cnt     Score    Error  Units
AddTest.testAdd   avgt   20   214.740 ±  4.323  ms/op
AddTest.testAdd1  avgt   20  1138.269 ± 32.062  ms/op

The amusing thing is that using 1.8.0.25 the results are strictly opposite:

# JMH 1.9 (released 40 days ago)
# VM invoker: C:\Program Files\Java\jdk1.8.0_25\jre\bin\java.exe
# VM options: <none>

Benchmark         Mode  Cnt     Score    Error  Units
AddTest.testAdd   avgt   20  1126.126 ± 22.120  ms/op
AddTest.testAdd1  avgt   20   217.145 ±  1.905  ms/op

However on 1.8.0_40 both versions are fast:

# JMH 1.9 (released 40 days ago)
# VM invoker: C:\Program Files\Java\jdk1.8.0_40\jre\bin\java.exe
# VM options: <none>

Benchmark         Mode  Cnt    Score   Error  Units
AddTest.testAdd   avgt   20  218.925 ± 5.093  ms/op
AddTest.testAdd1  avgt   20  217.066 ± 1.427  ms/op

In all of these cases add and add1 methods are inlined into the caller method. Seems that it's just related to internal changes with loop unrolling mechanism in JIT compiler: sometimes your loop is nicely unrolled, sometimes it's not.

Philippe Marschall · Accepted Answer · 2015-05-27T07:00:06.523

1

I can not reproduce this. Consider the following Microbenchmark:

@BenchmarkMode(Mode.Throughput)
@OutputTimeUnit(TimeUnit.MILLISECONDS)
public class BigDecimalBenchmark {

  static int i = 1024;

  @Benchmark
  public BigDecimal constructor() {
    return new BigDecimal(foo());
  }

  @Benchmark
  public BigDecimal localVariable() {
    int hash = foo();
    return new BigDecimal(hash);
  }

  private static int foo() {
    return i;
  }

}

Which gives the following output:

Benchmark                             Mode  Samples       Score      Error   Units
BigDecimalBenchmark.constructor      thrpt      100  180368.227 ± 4280.269  ops/ms
BigDecimalBenchmark.localVariable    thrpt      100  173519.036 ±  868.547  ops/ms

Update

Edited the benchmark to make foo() not inlineable.

edited May 27 '15 at 07:00

answered May 27 '15 at 06:34

Philippe Marschall

4,452
1
34
52

Which JVM version are you using? I can [reproduce](https://gist.github.com/amaembo/110c4499398d66880a73/edit) this. – Tagir Valeev May 27 '15 at 06:35
1.8.0u31, Java 7 is end of life – Philippe Marschall May 27 '15 at 06:36
Nevertheless the question was about Java 7. – Tagir Valeev May 27 '15 at 06:36
tried jdk 1.8. there is no difference between add() and add1(). so this is a bug in JVM. thanks folks – Water Guo May 27 '15 at 06:46
If you post your foo() I can include it in the benchmark. – Philippe Marschall May 27 '15 at 07:00
dug into this problem a bit more. it is caused by escape analysis. java 1.7 failed to recognize the escapable BigDecimal variable and caused lots of GC. it is fixed in 1.8 – Water Guo May 27 '15 at 15:26

Java BigDecimal strange performance behaviour

2 Answers2