Производительность отладки и выпуска

Question

Я встречал следующий абзац:

«Параметр« Отладка против выпуска »в IDE при компиляции кода в Visual Studio практически не влияет на производительность… сгенерированный код практически одинаков. Компилятор C # на самом деле не выполняет никакой оптимизации. Компилятор C # просто выплевывает IL… и во время выполнения все JITer выполняет всю оптимизацию. JITer имеет режим отладки / выпуска, и это сильно влияет на производительность. Но это не отменяет, запускаете ли вы конфигурацию Debug или Release вашего проекта, это отключает, подключен ли отладчик ».

Источник здесь , а подкаст здесь .

Может кто-нибудь направить меня к статье Microsoft, которая может это доказать?

Googling " Отладка C # против производительности выпуска " в основном возвращает результаты, говоря, что " Отладка сильно пострадала ", " выпуск оптимизирован ", и « не развертывать отладку в рабочей среде ».

Answer 1

Частично верно. В режиме отладки компилятор выдает отладочные символы для всех переменных и компилирует код как есть. В режиме релиза включены некоторые оптимизации:

• неиспользуемые переменные вообще не компилируются
• некоторые переменные цикла извлекаются из цикла компилятором, если они оказались инвариантами
• код, написанный под директивой #debug, не включен и т. Д.

Остальное зависит от JIT.

Редактировать: Полный список оптимизаций здесь любезно предоставлено Эрик Липперт

Answer 2

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

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

И, кроме того, вы сможете получить значимые результаты. «Медленнее» бессмысленно, потому что неясно, медленнее он на одну микросекунду или медленнее на двадцать минут. «На 10% медленнее в реальных условиях» более значимо.

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

Answer 3

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

Answer 4

С MSDN социальной

Это не очень хорошо задокументировано, вот что Я знаю. Компилятор испускает экземпляр System.Diagnostics.DebuggableAttribute. В отладочной версии Свойство IsJitOptimizerEnabled равно Правда, в релизной версии это Ложь. Вы можете увидеть этот атрибут в сборочный манифест с ildasm.exe

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

Отображение точек останова на исполнение адреса это работа отладчика. Он использует файл .pdb и информацию генерируется компилятором JIT, который предоставляет инструкцию IL для кода сопоставление адресов. Если бы вы написали ваш собственный отладчик, вы бы использовали ICorDebugCode :: GetILToNativeMapping ().

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

Answer 5

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

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

Виновником был Debug.WriteLine в одном из трудных циклов, которые выплевывают тысячи сообщений журнала, оставленных от сеанса отладки некоторое время назад. Кажется, что когда отладчик подключен и прослушивает такой вывод, возникают накладные расходы, которые замедляют работу программы. Для этого конкретного кода время выполнения было порядка 0,2-0,3 секунды, а при подключении отладчика - более 30 секунд.

Простое решение, просто удалите отладочные сообщения, которые больше не нужны.

Answer 6

То, что вы читаете, вполне допустимо. Выпуск обычно более скудный из-за оптимизации JIT, не включая отладочный код (#IF DEBUG или [Conditional ("DEBUG")]), минимальную загрузку символов отладки и часто не учитываемые - это меньшая сборка, которая сократит время загрузки. Различная производительность более очевидна при запуске кода в VS из-за более обширной PDB и загруженных символов, но если вы запускаете ее независимо, различия в производительности могут быть менее заметными. Определенный код оптимизируется лучше, чем другие, и он использует ту же эвристику оптимизации, что и в других языках.

Скотт дает хорошее объяснение оптимизации встроенного метода здесь

См. эту статью , в которой дается краткое объяснение, почему она отличается в среде ASP.NET для параметров отладки и выпуска.

Answer 7

В MSDN сайт ...

Конфигурация выпуска или отладки

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

Когда вы будете готовы распространять ваши приложение для конечных пользователей, создать выпустить сборку, которой будет много меньше и обычно будет намного лучшая производительность, чем соответствующая конфигурация отладки. Вы можно установить конфигурацию сборки в Панель сборки дизайнера проекта, или на панели инструментов Build. Для большего информацию смотрите в разделе Конфигурации сборки.

Answer 8

Режимы отладки и выпуска имеют различия. Существует инструмент Fuzzlyn : это фаззер, который использует Roslyn для генерации случайных программ на C #. Он запускает эти программы в ядре .NET и гарантирует, что они дают одинаковые результаты при компиляции в режиме отладки и выпуска.

С помощью этого инструмента было обнаружено и зарегистрировано много ошибок.

Answer 9

Я недавно столкнулся с проблемой производительности. Полный список продуктов занимал слишком много времени, около 80 секунд. Я настроил БД, улучшил запросы и не было никакой разницы. Я решил создать TestProject и обнаружил, что тот же процесс был выполнен за 4 секунды. Затем я понял, что проект находится в режиме отладки, а тестовый проект - в режиме выпуска. Я переключил основной проект в режим выпуска, и полный список продуктов занял всего 4 секунды, чтобы отобразить все результаты.

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

Answer 10

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