Autoboxing versus manual boxing in Java

Question

Why is the second piece of code faster?

Map<Integer, Double> map = new HashMap<Integer, Double>();
for (int i = 0; i < 50000; i++) {
    for (double j = 0.0; j < 10000; j++) {
        map.put(i, j);
    }
}

Map<Integer, Double> map=new HashMap<Integer, Double>();
for (int i = 0; i < 50000; i++) {
    for (double j = 0.0; j < 10000; j++) {            
        map.put(new Integer(i), new Double(j));
    }
}

Window

Try to wrap the both parts around and microbenchmark it again. – Millpond

because outside your contrived micro-benchmark which is incorrect, it doesn't matter since this will be optimized away but JIT eventually in the real world. – Subserve

Answer 1

Autoboxing uses Integer.valueOf, which internally caches Integer objects for small integers (by default -128 to 127, but the max value can be configured with the "java.lang.Integer.IntegerCache.high" property - see the source code of Integer.valueOf), so it is different from calling new Integer directly. Because Integer.valueOf does a quick check for the magnitude of the integer value before calling new Integer, it's a little bit faster to call new Integer directly (though it uses more memory if you have lots of small integers). Allocation in Java is very fast, and the time doing GC is proportional to the number of live short-lived objects (i.e. not proportional to the amount of garbage), so GC is also very fast.

But depending on the JVM version and which optimizations are enabled, there is the scalar replacement optimization, which can in produce a much bigger performance difference when allocating short-lived objects (in your example that optimization can't be done, because you are storing the objects in a map, but in many other situations it's useful).

In recent JVM versions there is scalar replacement optimization (except in 1.6.0_18 where escape analysis is temporarily disabled), which means that allocations of short-lived objects can be optimized away. When scalar replacement in JVM was new, somebody made a benchmark where there was code similar to yours. The result was that the code which used primitives was fastest, the code with explicit new Integer() calls was nearly as fast as the one using primitives, and the code which used autoboxing was much slower. This was because autoboxing uses Integer.valueOf and at least back then scalar replacement optimization did not take that special case into consideration. I don't know whether the optimization has been improved since then.

Lifeanddeath

"Because Integer.valueOf does a quick check for the size of the integer before calling new Integer". A Java Integer is always the same size. – Tradeswoman

He means it checks the int value being passed to it to see if it's within the range of values that are cached. – Killam

Value and size have different meanings. – Tradeswoman

Technically it checks of the value of the integer, not the magnitude of the value. – Tradeswoman

Nice answer dude, +1 for mentioning "java.lang.Integer.IntegerCache.high" – Cia

Answer 2

Autoboxing will use Integer.valueOf and Double.valueOf. There is some overhead in calling those methods (although it will eventually get inlined). Also Integer.valueOf does some checking for low-values to use pooled instances, which is not frequently a win in your code (although it could reduce heap size a little). Pooled instances may be a win where they reduce heap size, GC times and could even improve equality test performance..

But, in general, it's a microoptimisation which you should, in general, ignore.

Pinfish

Answer 3

Because the results of microbenchmarks are unreliable?

Also, auto-boxing is done using Integer.valueOf() and Double.valueOf(), not the constructors.

Airdrie