JVM Optimization Example

Came across an interesting example of optimization with dynamic compilation.

public class StupidMathTest {
public interface Operator {
public double operate( double d);
}

public static class SimpleAdder implements Operator {
public double operate( double d) {
return d + 1.0;
}
}

public static class DoubleAdder implements Operator {
public double operate( double d) {
return d + 0.5 + 0.5;
}
}

public static class RoundaboutAdder implements Operator {
public double operate( double d) {
return d + 2.0 - 1.0;
}
}

public static void runABunch(Operator op) {
long start = System.currentTimeMillis();
double d = 0.0;
for ( int i = 0; i < 5000000; i++)
d = op.operate(d);
long end = System.currentTimeMillis();
System. out .println( "Time: " + (end-start) + " ignore:" + d);
}

public static void main( String [] args) {
Operator ra = new RoundaboutAdder();
runABunch(ra);
Operator sa = new SimpleAdder();
Operator da = new DoubleAdder();
runABunch(sa);
runABunch(da);
}
}

Method Runtime
SimpleAdder 88ms
DoubleAdder 76ms
RoundaboutAdder 14ms


* This source code was highlighted with Source Code Highlighter .

It seems that it is much faster to add 1 to double, adding 2 and taking away 1, than just adding 1 right away. And add 0.5 twice as fast as adding 1. Is it possible? (Answer: no.)

What happened here? After the training cycle, RoundaboutAdder and runABunch () are compiled, and the compiler performs a monomorphic call conversion (the conversion of a virtual method call to a direct method call is called a monomorphic call conversion) with Operator and RoundaboutAdder, so the first pass is quite fast. In the second pass (SimpleAdder), the compiler must perform de-optimization and rollback to the dispatching of the virtual method, so the second pass is performed more slowly due to the inability to optimize (delete) the call to the virtual function, time is spent on recompilation. The third pass (DoubleAdder) does less recompiling, so it runs faster.
')
So, what can we conclude from this "performance test"? Virtually none, except that testing the performance of dynamically compiled programming languages ​​is a much more insidious process than you might imagine.

Original article
www.ibm.com/developerworks/ru/library/j-jtp12214/index.html