Is ++(a = b); faster than a = b + 1;?

Question

Is it faster to use ++(a = b); instead of a = b + 1; ?

For my understanding, the first approach consists of the operations:

1. move the value of b to a
2. increment a in memory

while the second approach does:

1. push b and 1 to the stack
2. call add
3. pop the result to a register
4. move the register to a

Does it actually take less cycles? Or does the compiler (gcc for example) do an optimization so it does not make a difference?

Answer 1

edit: TIL that ++(a=b) is wrong illegal UB, at least in pre-C++11. Nevertheless, I'll discuss this assuming it's either legal or the compiler does what you expect.

Generally speaking, a = b + 1; is faster.

The optimizer will most surely make the same of both. If not, it is more likely to optimize the second version, because it is a very common thing to write, and omtimizers are more likely to recognize common things than weird corner cases.

Why do I say it should be the same after optimization, but the second is faster? Because of the fellow developers. Everyone recognizes a = b + 1; immediately. Noone really has to think about it. The other case is more likely to trigger a reaction in the likes of "wtf is he doing there, and why ?". Many people will figure out eventually what you did there. Some will not. Some might even introduce bugs because of it. Few people will find out why you did it and nevertheless stumble each time they have to read that line. Everyone will lose time wondering while reading that line. That's why the other is faster.

Caveat: all this is written silently assuming that you are talking of builtin types, like int s or pointers. Your interpretation of what the two do supports that. If we're talking of UDTs, the two lines are not even guaranteed to do the same. It then depends completely on how operator= , operator++ and operator+ and maybe the conversion from int are implemented. Nevertheless, if the implementations make you conside to write ++(a=b) , they are most likely bad implementations and should be improved rather than hacked around.

tl;dr: if I'd catch you doing ++(a=b) in any codebase I work on, we'd have to have a serious talk ;-)

Answer 2

There is no simple answer to this question. The question has been flagged with C++ so we have no way of knowing what this code is actually doing without knowing the precise type of all the operands. Also, the context within which the code appears will make a difference to the way the optimiser generates code - the compiler could alias the variables and move the increment into instructions further down the program, for example, into effective address calculations for the two variables.

But the real question is, why do you care? As Arne said above, readability is far more important and you've not posted a scenario whereby any difference would have a measurable effect.

Only worry about it if it is actually causing a problem.

Answer 3

With optimizations on, they generate exactly the same code for me so they will perform exactly the same. This shouldn't be a surprise as the effects of both statements are exactly the same.

++(a = b); is undefined behaviour because there are two unsequenced modifications to a .

\n

Although the value computation of a in a = b is sequenced before the modification of a due ++ , the side-effect of a = b (storage to a ) is unsequenced relative to the side-effect of ++ (again, storage to a ).