This question already has an answer here:

Is there a performance difference between using ++x over x++ increment operators?

I've see developers use ++x in loops where I would normally write x++ out of habit.

For example;

 for(int x=0; x < 10; ++x)

There would be no difference in the results between ++x or x++. So I'm wondering if there is a reason some people do it this way.

Now I know the increment operator is handled internally differently depending on the language. So if there is a difference in performance for PHP, Java, C#, C++ or JavaScript. I'd like to know which language.

marked as duplicate by Kilian Foth, amon, gnat, Bart van Ingen Schenau, Karl Bielefeldt Apr 24 '14 at 12:29

This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.

  • They do two entirely different things. So if they are writting ++X there is a reason other then performace. – Ramhound Apr 24 '14 at 11:06
  • 1
    @Ramhound I'm asking when used in a context where there is no difference in the outcome. – Reactgular Apr 24 '14 at 11:09
  • 1
    You've heard of the streetlight effect? You're not alone in falling for it. There are so many questions like this on SO, where people wonder if language feature X is faster than Y, when real performance issues are totally elsewhere. For one thing, you can only find them after you're written and run a program and (dare I say it) -profiled- it. – Mike Dunlavey Apr 26 '14 at 1:08

For simple integers; NO, any decent peephole optimizer will see the value isn't used and use the best option available.

For more complex (overloaded) types in C++ (like iterators); possibly, the pre and post increment expand to different methods which may be completely different. Typically the post increment need to make a copy of itself before incrementing.

  • doh! I forgot about compiler optimization. – Reactgular Apr 24 '14 at 11:01

In terms of the logical evaluation of the loop, there is of course no difference, so the question is: can you compile ++x into something more efficient than x++ ?

And yes, indeed you can if you look close enough. In order to perform the increment on the variable, you need to load its value onto the stack (or a register, or wherever - for the sake of simplicity, I'll just keep saying stack), then perform the increment operation. Your stack will then contain the incremented value at the top. That's the same for both ways though, so why is there a difference?

It does make a difference, once you start using these expressions in larger ones. Consider f(++x) and f(x++). In order to create code that performs the function call, you need to place its argument onto the stack. Now if the argument is x++, then you place x on the stack and call the method, which removes its arguments from the stack again. The problem is that after all of this, you need to again load x onto the stack in order to perform the increment operation.

That being said: while using ++x may give you a few CPU cycles of performance, this is absolutely not the sort of performance difference that you should even have on your radar.

In addition, as ratchet freak pointed out, the ++ operation itself can be overloaded in some languages, resulting in vastly more complex behaviors and even differing results. However, in these cases, I consider it a criminal act to inline these operations (or in case of different results to even define them as such). And once you consider the statement x++ or ++x in isolation, there's nothing interesting to be said about performance anymore anyways.


No, there is no consistent performance difference between these operators that holds true across a range of languages.

In most languages I would expect them to behave identically, down to the point of generating identical code. The reason is that each produces the identical outcome, and provided the compiler writer is on the job, it's relatively to perform peephole optimisation on this case with no risk of undesirable side-effects. There is simple no reason for one of them to be slower, if the compiler writer is up to scratch.

Having said that, some of those languages compile to intermediate code and it is possible that the two constructs target different intermediate code. In this case there might be a small difference in performance, but it would not be easy to predict which is faster.

If you really care, you will have to benchmark each construct on each target language. Even if you find there is a difference, I suggest you ignore it and simply write the code that feels natural and looks right. Any performance difference will be infinitesimal.

Not the answer you're looking for? Browse other questions tagged or ask your own question.