Where Preincrement is Faster than Postincrement

September 20, 2006

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()
{
   (void)clock_gettime(CLOCK_REALTIME,&s);
}
 
inline void stop()
{
   struct timespec now;
   (void)clock_gettime(CLOCK_REALTIME,&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++)
      v.push_back(x);
 
   {
      start();
      for (vector<int>::iterator i = v.begin(); i != v.end();++i)
	 (*i)++;
      stop();
   }
 
   {
      start();
      for (vector<int>::iterator i = v.begin(); i != v.end();i++)
	 (*i)--;
      stop();
   }
 
   return 0;
}
Compile with:
$ g++ itertest.cpp -lrt
Results in:
$ ./a.out
28ms
36ms
$ ./a.out
28ms
38ms
$ ./a.out
28ms
37ms
$ ./a.out
28ms
41ms

Related Posts

6 Comments

Comment March 20, 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 November 4, 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 November 3, 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 November 4, 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 November 11, 2009 by anonymous
My perspective is an optimizer won't fix ignorance. Well said.
Comment May 16, 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.