Что действительно делает опция «Оптимизировать код» в Visual Studio?

Question

Имя параметра говорит о чем-то, но что на самом деле делает Visual Studio / компилятор и каковы реальные последствия?

Редактировать: если вы ищете в Google, вы можете найти этот адрес , но это не совсем то, что я ищу. Интересно, что происходит на самом деле. Например, почему циклы получают меньше времени и т. Д.

Answer 1

Без оптимизации компилятор создает очень тупой код - каждая команда компилируется очень простым способом, так что она выполняет предназначенную вещь. По умолчанию в сборках Debug оптимизации отключены, поскольку без оптимизаций созданный исполняемый файл напрямую соответствует исходному коду.

Переменные, хранящиеся в регистрах

Как только вы включите оптимизацию, компилятор применяет множество различных методов, чтобы заставить код работать быстрее, в то же время делая то же самое. Наиболее очевидное различие между оптимизированными и неоптимизированными сборками в Visual C ++ заключается в том, что значения переменных хранятся в регистрах как можно дольше в оптимизированных сборках, а без оптимизации они всегда сохраняются в памяти. Это влияет не только на скорость кода, но и на отладку. В результате этой оптимизации отладчик не может надежно получить значение переменной во время пошагового выполнения кода.

Другие оптимизации

Существует несколько других оптимизаций, применяемых компилятором, как описано в / O Опции (Оптимизировать код) MSDN docs . Для общего описания различных методов оптимизации см. Статья по оптимизации компилятора Wikipedia .

Answer 2

С Блог Пола Вика :

• Он удаляет все инструкции NOP, которые мы в противном случае выпустили бы для помощи в отладке. Когда оптимизация выключена (и включена информация об отладке), компилятор будет выдавать инструкции NOP для строк, с которыми не связан фактический IL, но на которых вы, возможно, захотите установить точку останова. Наиболее распространенным примером чего-то подобного является «End If» оператора «If» - фактический IL не генерируется для End If, поэтому мы не испускаем NOP, отладчик не позволит вам установить точку останова в теме. Включение оптимизации заставляет компилятор не генерировать NOP.

• Мы делаем простой базовый анализ блоков сгенерированного IL, чтобы удалить любые блоки мертвого кода. То есть мы разбиваем каждый метод на блоки IL, разделенные инструкциями ветвления. Сделав быстрый анализ того, как блоки взаимосвязаны, мы можем определить любые блоки, в которых нет ответвлений. Таким образом, мы можем определить блоки кода, которые никогда не будут выполнены и могут быть опущены, делая сборку немного меньше. В этот момент мы также делаем небольшую оптимизацию веток - например, если вы переходите к другому оператору GoTo, мы просто оптимизируем первый GoTo, чтобы перейти к цели второго GoTo.

• Мы генерируем атрибут DebuggableAttribute с IsJITOptimizerDisabled, установленным в False. По сути, это позволяет JIT во время выполнения оптимизировать код так, как он считает нужным, включая переупорядочение и встраивание кода. Это даст более эффективный и меньший код, но это означает, что попытка отладки кода может быть очень сложной (как скажет любой, кто попробовал ее). Фактический список того, что такое JIT-оптимизация, - это то, чего я не знаю - возможно, кто-то, как Крис Брамм, в какой-то момент вмешается в это. Суть в том, что переключатель оптимизации позволяет выполнять оптимизацию, которая может усложнить установку точек останова и пошаговое выполнение кода.

Answer 3

Краткий ответ: используйте -Ox и позвольте компилятору выполнить свою работу.

Длинный ответ: эффект различного рода оптимизаций невозможно предсказать точно. Иногда оптимизация для быстрого кода на самом деле дает меньший код, чем при оптимизации по размеру. Если вы действительно хотите получить последние 0,01% производительности (по скорости или по размеру), вы должны сравнить различные комбинации параметров.

Кроме того, в последних версиях Visual Studio есть опции для более продвинутых оптимизаций, таких как оптимизация во время соединения и оптимизация на основе профиля.