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

Show 80 post(s) from this thread on one page
Page 1 of 3 123 Last
• 05-26-2007
thetinman
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?
• 05-26-2007
Salem
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.
• 05-26-2007
anon
They have a different meaning. Why do you ask?
• 05-26-2007
iMalc
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.
• 05-26-2007
Desolation
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.
• 05-26-2007
Dave_Sinkula
Quote:

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
Quote:

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.
• 05-26-2007
Hussain Hani
as said, they are different in meaning. If you wanna which is faster as you say, you would considering using profiler
• 05-31-2007
thetinman
Quote:

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?"
• 05-31-2007
thetinman
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.
• 05-31-2007
Daved
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.
• 05-31-2007
MacGyver
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

• 05-31-2007
JVene
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.
• 05-31-2007
brewbuck
Quote:

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