-5

For example, I want to print vector's content. What will be executed faster, the "traditional for" cycle(1), or the C++11 one(2)? Or there is no speed difference at all? Any information is appreciated.

1)

for (int i=0;i<FooBar_vector.size();i++)
    {
           cout<<FooBar_vector[i]<<endl;
    }

2)

for (auto &val : FooBar_vector) 
    {
           cout<< val <<endl;
    }
Alexander Revo
  • 719
  • 9
  • 15
DISTURBED
  • 63
  • 11
  • 2
    You could benchmark it and see... But honestly, if you compile with optimizations, they should be the same. If there was a difference (which would surprise me), I don't think it would be noticeable, as printing the text and flushing the stream will take the vast majority of the time, I expect. – Cornstalks Mar 13 '15 at 18:56
  • 1
    One quick thing worth noting is you could change `endl` to "\n". Then after the loop, call `cout.flush()` – inetknght Mar 13 '15 at 18:57
  • 1
    I -1'ed this question because "Which is faster... X or Y" is a question that should basically never be asked on SO. What you should be doing instead is profiling the code yourself. – John Dibling Mar 13 '15 at 18:58
  • If your optimizer don't suck, use range-based. If it does suck, use pointer arithmetic. Either way, the loop itself wont be the thief, the output will. – sp2danny Mar 13 '15 at 18:59
  • @JohnDibling "why is this code faster" is, in comparison, a better question (assuming optimization flags/compiler/hardware mentioned explicitly, a reproducible example, and the like) – Yakk - Adam Nevraumont Mar 13 '15 at 19:03
  • @Yakk: Agreed. 'Why' is a question I'd be happy to upvote and answer. – John Dibling Mar 13 '15 at 19:18
  • @DISTURBED you have a history of asking poorly received questions. I would advise looking at questions that are well received, and look how they differ: compare your question to http://stackoverflow.com/search?tab=newest&q=[c%2b%2b]%20[performance]%20score%3a3...%20is%3aquestion other C++ performance questions with positive scores. In addition, there are lots of resources (here) about how to ask a good question. Find low voted ones, and see why they got down voted. – Yakk - Adam Nevraumont Mar 13 '15 at 19:18
  • @DISTURBED: Check out the following link: a list of questions tagged both [c++] and [performance], sorted with highest-voted questions first. You'll find some common attributes. A preponderance of questions ask why, not what. They are accompanied with evidence of research, including how to replicate the research and what the results were. They are well-thought questions, and the asker has spent some time trying to fill the gaps in their knowledge themselves. – John Dibling Mar 13 '15 at 19:28
  • http://stackoverflow.com/questions/tagged/performance%20c%2b%2b?sort=votes&pageSize=15 – John Dibling Mar 13 '15 at 19:28
  • Your question, on the other hand, shows none of that research, and there is no evidence that you've given this question much thought at all. Instead, it looks like the question popped in to your mind recently, "Huh, I wonder if there's a performance difference between X and Y. Let's ask the world." – John Dibling Mar 13 '15 at 19:31

2 Answers2

5

An easy answer: use a profiler.

A better answer: Why are you worrying about performance? Use #2, it's clearer and less prone to errors/typos.

A answer: The overhead of streaming to cout probably far outweighs any loop overhead. But see the easy answer.

Matthew Moss
  • 1,258
  • 7
  • 16
2

There are no fundamental reasons why a ranged-based for loop would be slower than a manual loop. The code that a ranged-based for loop is defined to be identical to is a relatively optimal loop.

In your case, each loop iteration logically calls size(). If at any point in the loop the compiler becomes unable to prove that size() cannot change in your loop, the compiler must actually call size() (which typically involves subtracting two pointers) and check it. This could cost some performance in your manual loop case.

In the for(:) loop it could cost correctness, in that if the vector being looped over has its begin or end iterator (or current iterator) invalidated during the loop, the loop continues to loop over the old iterators and undefined behavior can result.

So the two loops are not (in general) equivalent.

In the cases where the looped-over range is unchanging, the for(:) loop will perform as well, or better, than most hand-crafted loops that just iterate over elements, because most hand-crafted loops don't make a copy of end() and compare against that copy.

In this particular case, the overhead of IO (and to a lesser extent, formatting) will massively overwhelm any loop overhead.

Yakk - Adam Nevraumont
  • 262,606
  • 27
  • 330
  • 524