С ++ вектор производительности не интуитивно понятный результат?

Question

Я работаю с мастером производительности в VS2010, который тестирует инструментарий (подсчет вызовов функций и время.)

После изучения векторов в C ++ STL я просто решил посмотреть, какую информацию я могу получить о производительности заполнения вектора 1 миллионом целых чисел:

#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);
  }
}

То, что я получаю: 2402,37 миллисекунды прошедшего времени для вышеперечисленного. Но я узнал, что векторы должны сами изменять размеры, когда у них заканчивается емкость, так как они непрерывны в памяти. Поэтому я подумал, что получу лучшую производительность, сделав одно дополнение к приведенному выше:

generate.reserve(1000000);

Однако это удваивает время выполнения программы примерно до 5000 миллисекунд. Вот скриншот вызовов функций, слева без строки кода выше и справа с. Я действительно не понимаю этот результат, и он не имеет смысла для меня, учитывая то, что я узнал о том, как определение емкости векторов, если вы знаете, что наполните ее тонной, это хорошая вещь. Задание резерва в основном удваивает большинство вызовов функций.

http://imagebin.org/179302

Answer 1

На скриншоте, который вы опубликовали, похоже, что вы компилируете без оптимизации, что делает недействительным любой тест, который вы делаете.кнопка «идти быстрее» на компиляторе и включение оптимизации.

Указывать компилятору работать медленно, а затем беспокоиться о том, что он медленнее, чем ожидалось, бессмысленно.Я не уверен, почему код становится медленнее , когда вы вставляете вызов reserve, но в отладочных сборках вставляется много проверок во время выполнения, чтобы перехватить больше ошибок, и вполне возможно, что reserve вызов заставляет выполнять больше таких проверок, замедляя код.

Включите оптимизации и посмотрите, что произойдет.:)

Answer 2

Вы выполнили все свои тесты в конфигурации выпуска?

Кроме того, попробуйте запустить вне профилировщика, если вы столкнулись с каким-либо артефактом, вызванным профилировщиком (добавьте ручные измерения времени в свой код - вы можете использовать clock() для этого).

Кроме того, вы случайно сделали опечатку и на самом деле назвали resize вместо reserve?