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

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.

"C makes it easy to shoot yourself in the foot; C++ makes it harder, but when you do, it blows away your whole leg."-Bjarne Stroustrup
Nearing the end of finishing my 2D card game! I have to work on its 'manifesto' though <_<

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.

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.

Either one could be faster; it depends on the types of x and y, the surrounding code, the compiler, and the processor. Looking at those statements as if they will map to particular sequences of machine code instructions is a mistake.

There are 10 types of people in this world, those who cringed when reading the beginning of this sentence and those who salivated to how superior they are for understanding something as simple as binary.