Отладка и производительность релиза

Я столкнулся с следующим абзацем:

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

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

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

Googling "Отладка С# debug vs release" в основном возвращает результаты, говорящие: "Отладка имеет большой успех", "оптимизация выпуска" и "не развертывайте debug to production".

ОТВЕТЫ

Ответ 1

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

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

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

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

>

Ответ 2

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

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

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

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

Ответ 3

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

Ответ 4

Из msdn social

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

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

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

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

Ответ 5

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

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

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

Ответ 6

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

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

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

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

Ответ 7

В msdn сайт...

Конфигурации Release and Debug

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

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

Ответ 8

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

Ответ 9

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

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