Сколько увеличения производительности (если таковые имеются) сервис окон может получить между отладочная сборка и сборка конечных версий и почему?
Для управляемого кода, если у вас нет большого количества вещей, условно скомпилированных для сборок DEBUG, разница должна быть небольшой - IL должен быть почти таким же. Джиттер генерируется по-разному при запуске под отладчиком или без него - компиляция в IL не сильно влияет.
Есть кое-что, что делает / optimize
при компиляции в IL, но они не особенно агрессивны. И некоторые из этих оптимизаций IL, вероятно, будут обработаны оптимизацией джиттера, даже если они не оптимизированы в IL (например, удаление nops).
Подробнее см. Статью Эрика Липперта http://blogs.msdn.com/ericlippert/archive/2009/06/11/what-does-the-optimize-switch-do.aspx :
Флаг / optimize не меняет большую часть нашей логики генерации и генерации. Мы стараемся всегда генерировать простой, проверяемый код, а затем полагаемся на джиттер для выполнения тяжелой работы по оптимизации, когда он генерирует настоящий машинный код. Но мы сделаем несколько простых оптимизаций с этим флагом.
Прочтите статью Эрика, чтобы узнать о том, что / optimize
работает иначе при генерации IL.
Что ж, хотя вопрос повторяется, я чувствую, что некоторые из лучших ответов в исходном вопросе находятся в самом низу. Лично я видел ситуации, когда существует заметная разница между режимами отладки и выпуска. (Пример: Производительность свойства , где была двукратная разница между доступом к свойствам в режиме отладки и в режиме выпуска). Будет ли эта разница присутствовать в реальном программном обеспечении (а не в программе, подобной тесту), является спорным, но я видел, как это происходило в одном продукте, над которым я работал.
Из ответа Нила на исходный вопрос, из msdn social :
Это плохо документировано, вот что я знаю. Компилятор генерирует экземпляр атрибута System.Diagnostics.DebuggableAttribute. В отладочной версии свойство IsJitOptimizerEnabled имеет значение True, в версии выпуска - False. Этот атрибут можно увидеть в манифесте сборки с помощью ildasm.exe.
JIT-компилятор использует этот атрибут для отключения оптимизаций, которые затрудняют отладку. Те, которые перемещают код как инвариантный к циклам подъем. В отдельных случаях это может иметь большое значение в производительности. Хотя обычно не так.
Отображение точек останова на адреса выполнения - задача отладчика. Он использует расширение.pdb и информацию, сгенерированную JIT-компилятором, который предоставляет инструкцию IL для кодового сопоставления адресов. Если бы вы написали свой собственный отладчик, вы бы использовали ICorDebugCode :: GetILToNativeMapping ().