# Which Operation is Faster "=" or "+=" ?

This is a discussion on Which Operation is Faster "=" or "+=" ? within the C++ Programming forums, part of the General Programming Boards category; I have two operations. The value of "x" is already set to some value. One of the operations is Code: ...

1. ## Which Operation is Faster "=" or "+=" ?

I have two operations. The value of "x" is already set to some value. One of the operations is
Code:
`x =  y`
and the other is
Code:
`x +=  y`
Is one a tiny bit faster than the other? My guess is that the first one is faster, but I'm not certain. Is the speed exactly the same?

2. Yes, one is likely to be a tiny bit faster than the other.

Now whether it's always the same answer is much harder to say.

One thing is for sure, it's hardly ever going to matter to you.

3. They have a different meaning. Why do you ask?

4. It depends on the definitions of x & y, the code surrounding the usage of them, and the definitions of operator = and operator += for the types of x & y.

If the answer were ever as simple as a is faster than b (and they do the same thing) then we wouldn't have b.

5. Besides, chances are that your compiler will optimize it for you and you really shouldn't start optimizing before you have a bottleneck in your program. Not to mention that such little changes in your program couldn't make a huge difference.

6. Originally Posted by thetinman
I have two operations. The value of "x" is already set to some value. One of the operations is
Code:
`x =  y`
and the other is
Code:
`x +=  y`
Is one a tiny bit faster than the other? My guess is that the first one is faster, but I'm not certain. Is the speed exactly the same?
As others have pointed out, the question does not compare apples and apples. If you meant to compare
Code:
`x = x + y;`
with
Code:
`x += y;`
Then there is a difference. In C standardese it is
A compound assignment of the form E1 op= E2 differs from the simple assignment expression E1 = E1 op (E2) only in that the lvalue E1 is evaluated only once.
Whether or not one is faster may or may not be true on a given implementation.

Of course, all this may be moot in C++ if it is not built-in types.

7. as said, they are different in meaning. If you wanna which is faster as you say, you would considering using profiler

8. Originally Posted by Dave_Sinkula
As others have pointed out, the question does not compare apples and apples. If you meant to compare
Code:
`x = x + y;`
with
Code:
`x += y;`
Then there is a difference. In C standardese it isWhether or not one is faster may or may not be true on a given implementation.

Of course, all this may be moot in C++ if it is not built-in types.
What's wrong with comparing apples and oranges? I could ask a simple question such as "Which one has more fiber?" or "Which has more vitamin C?"

9. I thought maybe there would be some theoretical answer to this, for example, one operation requires two reads, one add, and one write, and the other operation only requires one read and one write.

10. One operation does an assignment. The other does addition and assignment.

It's just unusual to question which one is faster when they do different things, since normally the point of identifying the faster one is to choose it when both options are possible. Since these two things do different things, there isn't as much reason to identify which is faster.

11. Assuming x and y are ints... the assembly instructions would be something like this on an x86 processor:

For x = y;

Code:
```mov eax, y
mov x, eax```
For x += y; (or even x = x + y)

Code:
```mov eax, x
mov x, eax```

12. Theory can go deeper than that.

With a simple assignment, and nothing else to go on (context), the optimizer could evaporate the assignment into nothing.

For example, say the purpose was to preserve the original y and operate upon x as a temporary local value. Depending on context, the compiler might not need to bother.

Like other posters point out, the type is an all important notion of this context. If x & y are objects, these two operator overloads (at least += must exist), must be consulted to offer any meaningful answer.

Assuming an atomic primitive, and further assuming that the context of the code is such that the compiler doesn't optimize the assignment into oblivion, the assignment is a simple move, as MacGyver has pointed out.

In the increment version, while there is another step in the assembler, it may depend on the processor's design & RAM as to whether that actually takes longer in real time.

It's instructive to try examples like this on various CPU targets and see how there are times when speed is affected as much by ancillary system components that anything we can do it code.

13. Originally Posted by MacGyver
Assuming x and y are ints... the assembly instructions would be something like this on an x86 processor:
Actually, on x86 the CPU can add directly into a memory location, so the x += y code would (or at least could) look like:

Code:
```mov eax, y