Преимущества опции «Оптимизировать код» в сборке Visual Studio

Question

Большая часть нашего кода выпуска C # построена с отключенной опцией «Оптимизировать код». Я считаю, что это позволяет более легко отлаживать код, созданный в режиме Release.

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

И может ли какая-либо конкретная платформа пострадать хуже? Например. мультипроцессорный / 64 бит.

Answer 1

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

Если вам интересно, какие оптимизации выполняет компилятор C #, а не джиттер, при включенном переключателе оптимизации, см .:

http://blogs.msdn.com/ericlippert/archive/2009/06/11/what-does-the-optimize-switch-do.aspx

Answer 2

Полная информация доступна на http://blogs.msdn.com/jaybaz_ms/archive/2004/06/28/168314.aspx.

Вкратце ...

В управляемом коде JITter во время выполнения выполняет почти всю оптимизацию. Разница в генерируемом IL от этого флага довольно мала.

Answer 3

На самом деле, есть разница, иногда довольно значительная. Что действительно может повлиять на производительность (так как это то, о чем JIT не полностью заботится):

• Ненужные локальные переменные (т. Е. Большие кадры стека для каждого вызова)
• Слишком общие условные инструкции, JIT переводит их довольно простым способом.

• Ненужное разветвление (также плохо обслуживается JIT - в конце концов, у него не так много времени, чтобы выполнить все интеллектуальные оптимизации)

  Итак, если вы делаете что-то числовое - включите оптимизацию. В противном случае вы не увидите никакой разницы.

Answer 4

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

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

Answer 5

Я считаю, что со сложным кодом, интенсивно использующим процессор (код, который я использую, представляет собой симуляцию Монте-Карло, которая может порождать достаточное количество потоков, чтобы на 100% использовать компьютер. Это было протестировано в среде с 36 ядрами), снижение производительности может быть до 4 раз выше! Симуляция, которая занимает 2 часа, займет около 9 часов без флага оптимизации. (путей около 500 000, и для каждого пути есть 500 шагов для около 2000 различных объектов с очень сложным расчетом для каждого объекта).