Reputation: 6780
Background
Recently I posted an answer recommending something like:
x = x + 2;
Someone commented "Please use x += 2;
instead."
Having studied assembly language and compilers to some degree, I always assumed that these two statements would be reduced to the same assembly instructions. Therefore, I also thought that there would be no performance difference between the two, and that the only difference was a matter of opinion and style.
After recieving the above comment, I was curious, and did a quick google and SO search, which returned nothing.
My Question
Is there any performance difference between x = x + 2;
and x += 2
in java? Or is the only difference in readability and style, making the choice between the two a matter of opinion?
Please provide evidence, not opinion.
Upvotes: 3
Views: 643
Reputation: 3105
Below is what Eclipse compiler does (see the edit below).
Java code:
public static void x( int x)
{
x = x + 2;
}
Byte code:
public static void x(int);
Code:
0: iinc 0, 2
3: return
Java code:
public static void x( int x)
{
x += 2;
}
Byte code:
public static void x(int);
Code:
0: iinc 0, 2
3: return
As you can see, they compile to the same byte code. Java compiler heavily optimizes your code, so do not try to optimize it for trivial things, especially at the expense of readability.
Edit: Turns out not all compilers compile these statements to the same byte code. However, the original point still stands. Do not try to optimize your Java code for trivial things, especially at the expense of readability; because JIT compiler heavily optimizes your code while compiling the byte code into native machine code, even if some Java compilers skip some optimizations.
Upvotes: 2
Reputation: 1650
Generated bytecodes for the two pieces of code are different on my machine (as are most likely on yours), but that doesn't matter. First, machine code actually run by JVM after optimizations might be the same; second, in practice you won't notice any difference. Try benchmarking it yourself (this PDF presentation explains why you shouldn't), say, in a loop, and you'll see that you get all sorts of results that can differ n-fold between runs and/or after minor changes, and that happens in a surrounding that you made as predictable as you could. Imagine what happens in the real code where any of these lines is by no chance a substantial CPU-spender.
Running a proper JMH microbenchmark for this code says that it runs in ~3-4 nanoseconds in both variants (together with loading the initial value from a field and returning result from the method, or else the whole method might be thrown away). I'm a bit skeptical that some framework can measure time with such accuracy on my desktop, but what I do think is that either that is true or actual timings of these two pieces of code are drowned in other costs (calling a method? loading a value? returning a value?).
Benchmark Mode Cnt Score Error Units
MyBenchmark.f1 thrpt 30 281747,576 ± 9748,881 ops/ms
MyBenchmark.f2 thrpt 30 289411,317 ± 8951,254 ops/ms
For the sake of completeness, the benchmark I used is
import org.openjdk.jmh.annotations.*;
import java.util.concurrent.*;
@State(Scope.Thread)
@OutputTimeUnit(TimeUnit.MILLISECONDS)
public class MyBenchmark {
public int a = 0xDEADBEAF;
@Benchmark
public int f1() {
int x = a;
x += 2;
return x;
}
@Benchmark
public int f2() {
int x = a;
x = x + 2;
return x;
}
}
Run with 10 warmup iterations, 10 measuring iterations, 3 forks.
Upvotes: 0
Reputation: 417
I believe the only difference is readability. When studying this in class we were told thatx += 2
is actually less common.
Answers on this question seem to suggest that it depends on the compiler that you use, the accepted answer says that with most compilers it is identical.
This other question is specific to Java and provides a lot more evidence.
Upvotes: 0
Reputation: 655
The compiler executes both the statements in the same fashion and there is no difference in the execution time or performance whatsoever. x+=2
is interpreted by the compiler as x = x+2 and should have no difference in exec time.
Upvotes: -1