C ++矢量性能非直观结果？

Question

I am fiddling with the performance wizard in VS2010, the one that tests instrumentation (function call counts and timing.)

After learning about vectors in the C++ STL, I just decided to see what info I can get about performance of filling a vector with 1 million integers:

#include <iostream>
#include <vector>

void generate_ints();

int main() {
  generate_ints();
  return 0;
}

void generate_ints() {
  typedef std::vector<int> Generator;
  typedef std::vector<int>::iterator iter;
  typedef std::vector<int>::size_type size;

  Generator generator;

  for (size i = 0; i != 1000000; ++i) {
    generator.push_back(i);
  }
}

What I get is: 2402.37 milliseconds of elapsed time for the above. But I learnt that vectors have to resize themselves when they run out of capacity as they are contiguous in memory. So I thought I'd get better performance by making one addition to the above which was:

generate.reserve(1000000);

However this doubles the execution time of the program to around 5000 milliseconds. Here is a screenshot of function calls, left side without the above line of code and right side with. I really don't understand this result and it doesn't make sense to me given what I learnt about how defining a vectors capacity if you know you will fill it with a ton is a good thing. Specifying reserve basically doubled most of the function calls.

http://imagebin.org/179302

Answer 1

From the screenshot you posted, it looks like you're compiling without optimization, which invalidates any benchmarking you do.

You benchmark when you care about performance, and when you care about performance, you press the "go faster" button on the compiler, and enable optimizations.

Telling the compiler to go slow, and then worrying that it's slower than expected is pointless. I'm not sure why the code becomes slower when you insert a reserve call, but in debug builds, a lot of runtime checks are inserted to catch more errors, and it is quite possible that the reserve call causes more such checks to be performed, slowing down the code.

Enable optimizations and see what happens. :)

Answer 2

Did you perform all your benchmarks under Release configuration?

Also, try running outside of profiler, in case you have hit some profiler-induced artifact (add manual time measurements to your code - you can use clock() for that).

Also, did you by any chance make a typo and actually called resize instead of reserve ?