Sign inorRegister Site is for SALE!

Is it reasonable to use the prefix increment operator ++it instead of postfix operator it++ for iterators?

I decided to find out if there is practical sense in writing ++iterator instead of iterator++ when handling iterators. My interest in this question arouse far not from my love to art but from practical reasons. We have intended for a long time to develop PVS-Studio not only in the direction of error search but in the direction of prompting tips on code optimization. A message telling you that you'd better write ++iterator is quite suitable in the scope of optimization.

But how much relevant is this recommendation nowadays? In ancient times, for instance, it was advised not to repeat calculations. It was a good manner to write:

TMP = A + 10;
X = TMP + B;
Y = TMP + C;

instead of

X = A + 10 + B;
Y = A + 10 + C;

Such subtle manual optimization is meaningless now. The compiler would handle this task as well. It's just unnecessary complication of code.

Note for pedantic ones. Yes, you'd better not repeat calculations and calculate long expressions, which are used several times, separately. What I'm talking about is that there is no reason in optimizing simple cases like the one I have mentioned.

Well, we have digressed from our main point which is the question if the advice to use the prefix increment instead of postfix increment for operators is obsolete nowadays; if we should store our mind with one more subtle thing. Perhaps the compiler learned to optimize prefix increments long ago.

A bit of theory at first for those who are not familiar with the topic. All the rest may scroll the text a bit.

The prefix increment operator changes an object's state and returns itself in the changed form. The prefix increment operator in the iterator class to handle std::vector may look this way:
_Myt& operator++()
{ // preincrement
return (*this);

The situation with the postfix increment is more complicated. The object's state must change but it is the previous state which is returned. An additional temporary object is created:
_Myt operator++(int)
{ // postincrement
_Myt _Tmp = *this;
return (_Tmp);

If we want to just increment the iterator's value, it turns out that the prefix operator is more preferable. That is why, here you are one of the tips concerning software micro-optimization: write "for (it = a.begin(); it != a.end; ++it)" instead of "for (it = a.begin(); it != a.end; it++)". In the latter case, an unnecessary temporary object is created, which reduces performance.

You may read about all this in detail in the book by Scott Meyers "Efficient use of C++. 35 new recommendations on improving your programs and projects" (Rule 6. Distinguish between prefix increment and decrement operators) [1].

The theory is over. Now practice. Is there sense in replacing the postfix increment with the prefix one in code?
size_t Foo(const std::vector<size_t> &arr)
size_t sum = 0;
std::vector<size_t>::const_iterator it;
for (it = arr.begin(); it != arr.end(); it++)
sum += *it;
return sum;

I know that we may wander into the depths of philosophy now. Say, it may turn out that some other class would become the container instead of vector and iterators in this new class would be very complex and heavy; when copying the iterator, we would have to establish a new connection to the database and so on. So, you must always write ++it.

But it's theory. But in practice, when we encounter such a loop in our code, is it reasonable to replace it++ with ++it? Cannot we rely on the compiler that will guess itself that it can throw away an unnecessary iterator?

The answers are strange but the reason why we give them will become evident through further experiments.

Yes, we must replace it++ with ++it.

Yes, the compiler will optimize the code and it won't matter what increment we use.

I chose an "average compiler" and created a test project for Visual Studio 2008. It has two functions which calculate the sum using it++ and ++it and also estimates their running time. You may download the project here. Here is the code of functions the speed of which was measured:

1) Postfix increment. iterator++.
std::vector<size_t>::const_iterator it;
for (it = arr.begin(); it != arr.end(); it++)
sum += *it;

2) Prefix increment. ++iterator.
std::vector<size_t>::const_iterator it;
for (it = arr.begin(); it != arr.end(); ++it)
sum += *it;

Working time in the Release version:
iterator++. Total time : 0.87779
++iterator. Total time : 0.87753

This is the answer to the question if the compiler can optimize the postfix increment. Sure it can. If you study the implementation (assembler code), you will see that the both functions are implemented with the same instruction set.

Now let's answer the question what for we should replace it++ with ++it then. Let's measure the speed of functions in the Debug version:
iterator++. Total time : 83.2849
++iterator. Total time : 27.1557

There is practical sense in writing the code so that it slows down only 30 times and not 90 times.

Of course, the speed of Debug versions is not so crucial for many programmers. But if a program does something for a long time, sure such a large slow-down might be crucial, for instance, from the viewpoint of unit-tests. So, it is reasonable to optimize the speed of the Debug version.

I carried out one more experiment to find out what I would get using the good old size_t for indexing. I know it doesn't relate to the topic we are discussing and I understand that we cannot compare iterators with indexes and that the former are higher-level entities. But still I wrote and measured the speed of the following functions just out of curiosity:

1) Classic index of the size_t type. i++.
for (size_t i = 0; i != arr.size(); i++)
sum += arr[i];
2) Classic index of the size_t type. ++i.
for (size_t i = 0; i != arr.size(); ++i)
sum += arr[i];

The speed in the Release version:
iterator++. Total time : 0.18923
++iterator. Total time : 0.18913

The speed in the Debug version:
iterator++. Total time : 2.1519
++iterator. Total time : 2.1493

As we had expected, the speeds of i++ and ++i coincided.

Note. Code with size_t works faster in comparison to iterators due to absence of array overrun check. We can make the loop with iterators as fast in the Release version by adding the line "#define _SECURE_SCL 0".

To make it easier for you to evaluate the results of speed measurements, I present them in the table (Figure 1). I have converted the results taking the running time of Release version with iterator++ for a unit. I also rounded them off a bit to make them clearer.

Figure 1. The running time of sum calculation algorithms.
Figure 1. The running time of sum calculation algorithms.

Each one of you can draw your own conclusions. They depend upon tasks you are solving. Personally I came to the following conclusions:
  1. I made sure that it is reasonable to perform such micro-optimization. We should implement the search of postfix increment iterators in PVS-Studio when their previous states are not used. Some programmers will find this functionality useful. All the rest can disable it in the settings if they don't need it.
  2. I will always write ++it. I did so before but I did it "just in case". Now I can see how useful it is because I regularly launch debug versions. In general, of course, ++it has a very slight influence on the running time. But if I don't make such small optimizations in different places of the code, it will be too late and the profiler won't help me. Bottlenecks will be spread throughout the code.
  3. I notice that the PVS-Studio analyzer is spending more and more time inside various functions of std::vector, std::set, std::string classes and the like. This time is growing more and more because new diagnostic rules appear - and it is quite convenient for us to write them using STL. So, I think - hasn't that frightful time come when the program acquires its own specialized string classes, array classes and so on. Well, it is just my cares... Don't listen to me! I tell people seditious things... Sh!..

P. S.
Someone will say now that untimely optimization is evil [2]; when you need optimization, you take the profiler and search for bottlenecks. I know this. And I got rid of certain bottlenecks long ago. But when I'm waiting for the tests to finish for 4 hours, I start thinking that it is a very good idea to gain at least 20% of speed. Such optimization is comprised of iterators, structure sizes, avoiding using STL or Boost in some fragments and so on. I believe that some developers agree with me.
  1. Meyers, Scott. More Effective C++: 35 New Ways to Improve Your Programs and Designs. Addison-Wesley, Reading, Mass., 1996. ISBN-10: 020163371X. ISBN-13: 9780201633719.
  2. Randall Hyde. The Fallacy of Premature Optimization.
Andrey2008 30 january 2012, 13:18
Vote for this post
Bring it to the Main Page


+1 hga January 30, 2012, 20:11
In ancient times, for instance, it was advised not to repeat calculations.

More to the point, in ancient times the PDP-11 had pre-decrement and post-increment addressing modes. And instruction space was at an extreme premium; the first PDP-11 UNIX(TM) was ported to (the original, later renamed the PDP-11/20) had 56KB of memory (the rest was for memory mapped Unibus cards, the only way it did I/O). Not that long afterwards came the PDP-11/45, which had a "split I and D" mode that in practice allowed a single process up to 65KB of code, 56KB of data and 8KB of stack. And UNIX(TM) was stuck there for a long time.

Leave a Reply

Avaible tags
  • <b>...</b>highlighting important text on the page in bold
  • <i>..</i>highlighting important text on the page in italic
  • <u>...</u>allocated with tag <u> text shownas underlined
  • <s>...</s>allocated with tag <s> text shown as strikethrough
  • <sup>...</sup>, <sub>...</sub>text in the tag <sup> appears as a superscript, <sub> - subscript
  • <blockquote>...</blockquote>For  highlight citation, use the tag <blockquote>
  • <code lang="lang">...</code>highlighting the program code (supported by bash, cpp, cs, css, xml, html, java, javascript, lisp, lua, php, perl, python, ruby, sql, scala, text)
  • <a href="http://...">...</a>link, specify the desired Internet address in the href attribute
  • <img src="http://..." alt="text" />specify the full path of image in the src attribute