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

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

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

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

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

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

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

Прочие оптимизации

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

Из блога Пол Вика:

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

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

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