Приложение Visual Studio работает очень медленно с отладкой

Question

У меня есть собственная программа на C ++, которая работает более чем в 20 раз медленнее при запуске с Debug ( F5 ), но работает с нормальной скоростью при использовании запуска без отладки ( Ctrl + F5 ).

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

Есть ли какие-то настройки, которые я выбрал неправильно или что-то в этом роде?

Answer 1

Установите для переменной среды _NO_DEBUG_HEAP значение 1 (как видно на http://preshing.com/20110717/the-windows-heap-is-slow-when-launched-from-the-debugger).

Это можно сделать и из Visual Studio.

Теперь это просто обходной путь, и мне любопытно узнать, как реорганизовать программу, которая страдает от такого рода проблем. У вас есть случайно много std :: map's, shared_ptr или других больших косвенных указаний?

Answer 2

Это, конечно, не вызвано определением символа _DEBUG или компиляцией кода в конфигурации отладки.Добавленный код отладки запускается независимо от того, присоединен ли отладчик к программе.

Обычно отладчик не влияет на выполнение кода, он остается в стороне, вызывая WaitForDebugEvent.Что блокирует его, пока операционная система не скажет, что произошло что-то примечательное.Это может вызвать кучу кода в отладчике, который может замедлить вашу программу.Вы можете увидеть события, перечисленные в документации по структуре DEBUG_EVENT.

Немного пометить их за пределами документации: отладчик включается и может замедлить вашу программу, когда:

• Программа загружает или выгружает DLL.Многое происходит во время загрузки, отладчик ищет файл с символами отладки (.pdb).Он может связаться с сервером символов, чтобы загрузить его.Любые точки останова, которые были установлены в исходном коде DLL, будут активированы.Это может быть довольно медленным, но эффект временный и, как правило, только замедляет запуск.Вы можете увидеть уведомление о загрузке / выгрузке в окне «Вывод».

• Программа вызывает исключение.Это активирует отладчик в момент возникновения исключения, «уведомление о первом шансе».Что может быть очень полезно, вы можете использовать флажок Отладка + Исключение, Брошенный, чтобы остановить отладчик при возникновении исключения.Вы можете увидеть уведомление в окне вывода.Этот замедляет код , который вызывает и чрезвычайно ловит исключения и, скорее всего, является источником вашего замедления.Никогда не используйте исключения для управления потоком.

• Поток запускается или завершается.Опять же, уведомление выводится в окно вывода.Вам нужно создать много потоков, чтобы замедлить работу вашей программы.

• Когда ваша программа использует OutputDebugString () для целей трассировки.Видна в окне вывода.Еще один хороший кандидат на замедление - вывод падает в область битов, если отладчик не подключен.У вас не должно возникнуть проблем с диагностикой этой причины, очевидным побочным эффектом является просмотр много сообщений в окне вывода.

• Когда программадостигает точки остановаНе так много причин быть озадаченным этим.Но вы можете установить точки останова, которые сильно замедляют работу программы, но не вызывают прерывание отладчика.В частности, условная точка останова, счетчик попаданий, фильтр и операция «Когда попадание» будут медленными.Используйте Debug + Windows + Точки останова для просмотра заданных точек останова.

Answer 3

Для меня разница в производительности между режимом отладки и режимом выпуска составляет примерно 40 .После некоторого копания кажется, что некоторые вещи способствуют разнице в производительности, но есть одна опция компилятора, которая удваивает мою производительность отладки почти бесплатно.

А именно, изменяя /ZI на /Zi.Описание см. на странице MSDN .

Я не использую редактировать и в любом случае продолжить .

Answer 4

Когда процесс создается под отладчиком, операционная система по умолчанию использует кучу отладки. Кучи отладки делает больше проверки вашей памяти, особенно на de-alloc.

Существует несколько возможных вариантов отключения кучи отладки:

1. Присоединение к процессу вскоре после запуска. Это позволит вам сознательно повысить производительность в режиме отладки и полностью осознавать режим, в котором вы работаете.

2. Добавить параметр переменной среды _NO_DEBUG_HEAP = 1.
   Это можно установить глобально для компьютера или для конкретного экземпляра Visual Studio.

   а. Глобально вы должны установить переменную среды через Панель управления → Система → Расширенные настройки системы → Переменные среды и добавить туда переменную _NO_DEBUG_HEAP = 1.
   Примечание. Это повлияет на КАЖДОЕ приложение, которое вы отлаживаете.

   б. Для экземпляра Visual Studio вы можете открыть командную строку, задав переменную среды _NO_DEBUG_HEAP = 1, а затем открыть Visual Studio из этой командной строки. Это повлияет только на процессы, созданные из этот экземпляр Visual Studio будет наследовать среду переменная.

3. Добавить поведение отладчика , это возможно для VS2015. Есть 2 способа переопределить это:

   а. Чтобы изменить конкретный проект, перейдите в свойства проекта: «Свойства конфигурации» → «Отладка» и измените для свойства «Среда» _NO_DEBUG_HEAP значение 1

   .

   б. Чтобы изменить для каждого проекта в Visual Studio, перейдите в Инструменты → Параметры → Отладка и установите флажок «Включить распределитель кучи отладки Windows (только собственный)».
   Примечание: если переменная окружения _NO_DEBUG_HEAP, упомянутая в 'a', установлена ​​на уровне проекта, она переопределит этот глобальный параметр.

Answer 5

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

Если вы используете сервер символов (включая общедоступный сервер символов Microsoft), это может увеличить время запуска, поэтому убедитесь, что в вашей переменной _NT_SYMBOL_PATH имеется локальный кэш символов, если это так.

Также среда IDE работает с включенной кучей отладки, но я не думаю, что это произойдет, если вы запустите ее вне среды IDE.

Answer 6

Никто не упоминал о закрытии неиспользуемых исходных окон.

После закрытия 20+ неиспользуемых окон пошаговое выполнение пошагового изменения исходного кода перешло с ~ 5 с до ~ .2 с. Этот необычно медленный проект загружает DLL динамически, и эта DLL также была той, через которую проходили (и имели открытые исходные окна), так что это, вероятно, связано. Однако это был C # (заголовок и теги не являются специфическими). ​​

Answer 7

Отладка Visual C ++ идет с большим количеством накладных расходов, особенно в STL.Попробуйте не определять _DEBUG, а определить NDEBUG.