Файлы PDB для производственного приложения и флаг «Оптимизировать код»

Question

Когда мне включать файлы PDB для производственной версии? Должен ли я использовать флаг Optimize code и как это повлияет на информацию, полученную из исключения?

Если есть заметное улучшение производительности, я бы хотел использовать оптимизацию, но если нет, я бы предпочел точную информацию об отладке. Что обычно делается для производственного приложения?

Answer 1

Если вы хотите увидеть исходные имена файлов и номера строк в ваших стековых трассах, сгенерируйте PDB, используя опцию pdb-only. Оптимизация отделена от генерации PDB, т.е. вы можете оптимизировать и генерировать PDB без снижения производительности.

С Справочник по языку C #

Если вы используете / debug: full, имейте в виду, что это оказывает некоторое влияние на скорость и размер оптимизированного JIT кода и небольшое влияние на качество кода с помощью / debug: full. Мы рекомендуем / debug: pdbonly или нет PDB для генерации кода выпуска.

Answer 2

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

Чтобы ответить на ваш второй вопрос, использование флага «Оптимизировать» с PDB означает, что любой «крах» стека будет отражен в трассировке стека . Я не уверен, что фактический номер строки может быть неправильным - это требует дополнительного расследования.

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

1. Измените конфигурацию выпуска, чтобы выдавать символы отладки. Это практически не влияет на производительность вашего приложения и очень полезно, если (когда?) Вам нужно отладить сборку релиза вашего приложения.

2. Компиляция с использованием новой конфигурации сборки выпуска, то есть с символами отладки и с оптимизацией. Обратите внимание, что 99% оптимизации кода выполняется компилятором JIT, а не компилятором языка.

3. Создайте текстовый файл в папке вашего приложения с именем xxxx.exe.ini (или dll или любой другой), где xxxx - это имя вашего исполняемого файла. Этот текстовый файл должен изначально выглядеть так:

   [.NET Framework Debugging Control]
   GenerateTrackingInfo=0
   AllowOptimize=1
   

4. С этими настройками ваше приложение будет работать на полной скорости. Если вы хотите отладить приложение, включив отслеживание отладки и, возможно, отключив (CIL) оптимизацию кода, просто используйте следующие параметры:

   [.NET Framework Debugging Control]
   GenerateTrackingInfo=1
   AllowOptimize=0 
   

РЕДАКТИРОВАТЬ Согласно комментарию cateye, это также может работать в размещенной среде , такой как ASP.NET.

Answer 3

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

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