Как сделать так, чтобы отладочные сборки MSVC работали быстрее

Question

У нас есть большое приложение на C ++, которое иногда нам нужно запускать как отладочную сборку, чтобы исследовать ошибки. Сборка отладки намного медленнее, чем сборка релиза, до такой степени, что она практически непригодна.

Какие приемы доступны для ускорения выполнения сборок MSVC Debug без ущерба для отладки?

Answer 1

Используйте #pragma optimize("", off) вверху выбранных файлов, которые вы хотите отладить в выпуске. Это дает лучшую трассировку стека / представление переменных.

Хорошо работает, если нужно всего несколько файлов, чтобы отследить ошибку.

Answer 2

Мы отключили отладку итератора с символами препроцессора:

_HAS_ITERATOR_DEBUGGING=0
_SCL_SECURE=0

Это немного помогло, но было не так быстро, как хотелось бы. Мы также сделали нашу отладочную сборку более похожей на релиз, определив NDEBUG вместо _DEBUG. Была пара других опций, которые мы тоже изменили, но я их не помню.

К сожалению, нам нужно было сделать все это, но наше приложение имеет определенный объем работы, который необходимо выполнять каждые 50 мсек, или его невозможно использовать. VS2008 из коробки даст нам ~ 60мс раз для отладки и ~ 6мс раз для выпуска. С упомянутыми выше настройками мы можем получить отладку до ~ 20 мс или около того, что по крайней мере пригодно для использования.

Answer 3

Почему бы вам просто не включить отладочную информацию в конфигурации релиза?

Answer 4

профилируйте приложение и посмотрите, сколько времени уйдет. После этого вы сможете увидеть, какую отладку нужно настроить.

Answer 5

Создайте ReleaseWithSymbols конфигурацию, которая определяет NDEBUG и не включает оптимизацию. Это даст вам лучшую производительность при сохранении точных символов для отладки.

Answer 6

Вы используете MFC?

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

Несмотря на это, если, скажем, в 10 раз медленнее, чем сборка релиза, это означает, что он тратит 1/10 своего времени на то, что необходимо, и 9/10 на что-то другое. Если, пока вы ждете этого, вы просто нажмете кнопку «пауза» и посмотрите на стек вызовов, скорее всего, 9/10, что вы точно увидите, в чем проблема.

Это быстрый и грязный, но эффективный способ найти проблемы с производительностью.

Answer 7

Существует несколько различий между сборками отладки и сборками выпуска, которые влияют как на отлаживаемость, так и на скорость. Наиболее важными являются определение _DEBUG / NDEBUG, оптимизация компилятора и создание отладочной информации.

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

Если вам нужна надежная информация о линии, включите и выключите оптимизацию. Это немного замедлит выполнение, но все равно будет быстрее обычной отладки, пока определение _DEBUG еще не установлено. Тогда вы можете сделать довольно хорошую отладку, только все, что имеет "#ifdef _DEBUG" или подобное вокруг него, не будет (например, призывы к утверждению и т. Д.).

Надеюсь, это поможет,

Jan

Answer 8

Какую VS вы используете? Мы недавно перешли с VS.net на VS2008, и я испытал ту же медлительность при отладке на высокопроизводительной машине в проекте> 500k LOC. Оказывается, база Intellisense была повреждена и постоянно обновлялась, но где-то зависала. Удаление файла .ncb решило проблему.