Where Preincrement is Faster than Postincrement

September 19, 2006
Home· Programming
Just a little example that shows the time differences between post and pre-increment on STL iterators. If you understand how they work, it's exactly as expected.

 * Times the difference between using ++i and i++ on iterators in a loop.
#include <iostream>
#include <vector>
#include <sys/time.h>
using namespace std;
struct timespec s;
inline void start()
inline void stop()
   struct timespec now;
   unsigned int diff = (unsigned int)((double)(now.tv_sec-s.tv_sec) * 1000.0) +
      (unsigned int)((double)(now.tv_nsec-s.tv_nsec) / 1000000.0);
   cout << diff << "ms" << endl;
int main()
   vector<int> v;
   for (unsigned int x = 0; x < 1000000;x++)
      for (vector<int>::iterator i = v.begin(); i != v.end();++i)
      for (vector<int>::iterator i = v.begin(); i != v.end();i++)
   return 0;

Compile with:
$ g++ itertest.cpp -lrt

Results in:
$ ./a.out
$ ./a.out
$ ./a.out
$ ./a.out

Related Posts


Comment 12:07pm on Tuesday 20th March 2007 by anonymous
You can't measure performance on unoptiimzed code; your test case is meaningless. Any reasonable compiler will optimize away your entire program. You must write a loop that does minimal but necessary work and re-test your timings on optimized code.
Comment 5:14am on Tuesday 4th November 2008 by Emil Wojak
The fact that it's unoptimized is irrelevant, when trying to prove, that preincrement is faster. I agree, that the compiler might optimize out copying the iterator when the value returned from postincrement operator is not used. This would make both increments at most equally fast. However, it is not a good practice to rely thoroughly on the optimizer and writing filthy code. Not always will the compiler be that smart, and using preincrement even on simple types develops good habits and makes your program independent of optimizer lottery.
Comment 2:24pm on Tuesday 3rd November 2009 by anonymous
"The fact that it's unoptimized is irrelevant, when trying to prove, that preincrement is faster" Well, If preincrement is NEVER faster in optimized code, I would find this observation pretty relevant don't you think? I do not agree with your perspective AT ALL. Nothing is worse than code which is hard to read because some douchebag obfuscates it with trivial optimizations that the compiler does anyway, like. using ">> 1" instead of "/ 2". My view is quite the opposite - rely on the optimizer as much as possible and keep the code clean and easy to read and maintain. And yes, in my opinion, "++i" makes the code a bit harder to read because it pops out as unusual.
Comment 12:39am on Wednesday 4th November 2009 by digitalpeer
This example is an exercise in understanding why this happens, which Emil understands. Preincrement is sometimes faster, even in optimized code. It all boils down to making a copy being more expensive than not. There is something to be said about maintaining readability and avoiding being cute, but the use of preincrement does not fall under either of those. A trivial optimization like this can make a huge impact. Preincrement isn't the only alternative to optimizing out a costly postincrement operation, but it doesn't matter if you don't understand the problem. My perspective is an optimizer won't fix ignorance.
Comment 5:56pm on Tuesday 10th November 2009 by anonymous
My perspective is an optimizer won't fix ignorance. Well said.
Comment 2:41pm on Wednesday 16th May 2012 by anonymous
People who trust the optimizer are too lazy or dumb to write smart code. After all, if average programmers were more skilled, ++i would not be an unusual sight at all.

Add Comment

No login required and anonymous if you prefer.
No html tags. URLs will be automatically linked. Spam protection is in place for email address. Click CAPTCHA image for new one.