Как запуск кода в отладчике делает его быстрее?

Question

Это никогда не случалось со мной. В Visual Studio у меня есть часть кода, которая выполняется 300 раз, я проверяю ее каждую итерацию с помощью счетчика производительности, а затем усредняю ​​ее. Если я запускаю код в отладчике, я получаю в среднем 1,01 мс, если я запускаю его без отладчика, я получаю 1,8 мс.

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

Я пытаюсь оптимизировать свой код, но прежде чем бросить меня на изменение кода, я хочу быть уверен в своих временах. Чтобы было с чем сравнить.

Что может вызвать это странное поведение?

Edit:

Некоторые уточнения:

Я использую тот же скомпилированный кусок кода: сборка релиза. Единственная разница - (F5 против CTRL-F5) Таким образом, оптимизация компилятора не должна быть задействована.

Поскольку каждое вычисленное время было очень маленьким, я менял способ измерения: теперь я рассчитываю 300 итераций, а затем делю на 300. У меня тот же результат.

О кэшировании: код выполняет некоторую взаимную корреляцию изображений с различными изображениями на каждой итерации. Этапы обработки не изменяются данными на изображениях. Поэтому я думаю, что кеширование не является проблемой.

Answer 1

Кажется, я понял это.

Если я добавлю Sleep (3000) перед запуском тестов, они дадут тот же результат.

Я думаю, это как-то связано с загрузкой misc. DLLs. В отладчике библиотеки были загружены до выполнения любого кода. За пределами отладчика dll загружались по требованию, а один или несколько загружались после запуска таймера.

Спасибо всем.

Answer 2

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

Answer 3

При таком способе вы, вероятно, получите очень ошибочные результаты ... вам следует использовать профилировщик. Вы должны прочитать эту статью под названием Опасности MicroBenchmarking :
http://blogs.msdn.com/shawnhar/archive/2009/07/14/the-perils-of-microbenchmarking.aspx

Answer 4

Прочитав ваши дополнительные данные, зазвонил дальний звонок ...

При запуске программы в отладчике она будет перехватывать как исключения C ++, так и структурированные исключения (выполнение Windows)

Одним событием, которое вызовет структурированное исключение, является деление на ноль, возможно, что отладчик быстро перехватит и отклонит это событие (в качестве обработки первого шанса исключения), пока код выпуска идет немного дольше , прежде чем что-то с этим делать.

, поэтому, если ваш код может генерировать такие или подобные исключения, стоит посмотреть на это.

Answer 5

Прежде чем погрузиться в сеанс оптимизации, ознакомьтесь с некоторыми фактами:

• доза имеет значение? доза это приложение работает в два раза медленнее, измеряется в течение разумного периода времени?
• как настроены сборки отладки и выпуска
• каково состояние этого проекта? Это полное программное обеспечение или вы профилируете одну функцию?
• как вы запускаете отладочные и сборочные выпуски, вы уверены, что тестируете при одинаковых условиях (например, параметры приоритета процесса)

Предположим, вы оптимизируете код, что вы имеете в виду?

Answer 6

Отладочная версия инициализирует переменные в 0 (обычно).
В то время как двоичный файл выпуска не инициализирует переменные (если код явно не делает). Это может повлиять на то, что код делает ziae цикла или целый ряд других возможностей.

Установите уровень предупреждения на самый высокий уровень (уровень 4, по умолчанию 3).
Установите флаг, который говорит об обработке предупреждений как об ошибках.

Перекомпилируйте и повторно протестируйте.

Answer 7

Вы выполняете точно такой же код в отладчике и вне отладчика или отлаживаете в отладчике и выпускаете снаружи? Если это так, код не совпадает. Если вы выполняете отладку и выпуск и видите разницу, вы можете отключить оптимизацию в выпуске и посмотреть, что это делает, или запустить ваш код в профилировщике в отладке и выпуске и посмотреть, что изменится.

Answer 8

Вероятно, это оптимизация компилятора, которая на самом деле ухудшает ваш код. Это крайне редко в наши дни, но если вы делаете странные, странные вещи, это может произойти.

Некоторые отладчики / IDE, такие как Visual Studio, автоматически обнуляют память для вас в режиме отладки; это может быть способствующим фактором.