Отладка по сравнению с выполнением Выпуска

From msdn social

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

На сайте msdn...

Release vs. Debug configurations

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

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