Назва параметра дещо говорить, але що насправді робить Visual Studio / компілятор і які реальні наслідки?
Редагувати: Якщо ви шукаєте в google, ви можете знайти цю адресу , але насправді це не я шукаю. Цікаво, що відбуваються справжні речі. Наприклад, чому цикли отримують менше часу тощо.
Відповіді:
Без оптимізації компілятор видає дуже німий код - кожна команда компілюється дуже просто, так що вона виконує задумане. У збірках налагодження за замовчуванням вимкнено оптимізацію, оскільки без оптимізацій створений виконуваний файл відповідає вихідному коду прямо.
Після того, як ви ввімкнете оптимізацію, компілятор застосовує безліч різних методів, щоб пришвидшити роботу коду, виконуючи все те саме. Найбільш очевидна різниця між оптимізованими та неоптимізованими збірками у Visual C ++ полягає в тому, що значення змінних зберігаються в регістрах якомога довше в оптимізованих збірках, тоді як без оптимізації вони завжди зберігаються в пам'яті. Це впливає не тільки на швидкість коду, але і на налагодження. В результаті цієї оптимізації налагоджувач не може надійно отримати значення змінної під час проходження коду.
Компілятор застосовує кілька інших оптимізацій, як описано в документах MSDN Параметри / O (Оптимізація коду) . Загальний опис різних методів оптимізації див. У статті «Оптимізація компілятора Вікіпедії» .
З блогу Пола Віка :
Він видаляє будь-які інструкції NOP, які ми б іншим чином видавали, щоб допомогти у налагодженні. Коли оптимізацію вимкнено (а інформацію про налагодження ввімкнено), компілятор видасть інструкції NOP для рядків, які не мають жодного фактичного IL, пов’язаного з ними, але які, можливо, ви захочете поставити точку зупинки. Найпоширенішим прикладом чогось подібного може бути "End If" оператора "If" - для End If не видається фактичного IL, тому ми не видаємо NOP, налагоджувач не дозволить вам встановити точку зупинки на цьому. Увімкнення оптимізації змушує компілятор не випускати NOP.
Ми робимо простий базовий блоковий аналіз сформованого ІЛ, щоб видалити всі мертві блоки коду. Тобто ми розбиваємо кожен метод на блоки ІЛ, розділені інструкціями гілок. Швидко проаналізувавши взаємозв’язок блоків, ми можемо визначити будь-які блоки, у яких немає гілок. Таким чином, ми можемо з’ясувати блоки коду, які ніколи не будуть виконуватися і можуть бути опущені, роблячи збірку трохи меншою. На цьому етапі ми також виконуємо незначні оптимізації гілок - наприклад, якщо ви переходите до іншого виразу GoTo, ми просто оптимізуємо перший GoTo, щоб перейти до цілі другого GoTo.
Ми видаємо DebuggableAttribute з IsJITOptimizerDisabled, встановленим на False. По суті, це дозволяє виконуваному JIT оптимізувати код, як він вважає за потрібний, включаючи переупорядкування та вбудовування коду. Це дасть більш ефективний і менший код, але це означає, що спроба налагодити код може бути дуже складною (як скаже вам кожен, хто його пробував). Фактичний список того, що таке оптимізація JIT, - це те, чого я не знаю - можливо, хтось, як Кріс Брумме, коли-небудь натякне на це. Довгий і короткий момент полягає в тому, що перемикач оптимізації забезпечує оптимізацію, яка може ускладнити встановлення точок зупинки та пройти через ваш код важче.
Коротка відповідь: використовуйте -Ox і нехай компілятор виконує свою роботу.
Довга відповідь: ефект різного роду оптимізацій неможливо точно передбачити. Іноді оптимізація для швидкого коду насправді дасть менший код, ніж при оптимізації за розміром. Якщо ви дійсно хочете отримати останні 0,01% продуктивності (за швидкістю або величиною), вам потрібно порівняти різні комбінації варіантів.
Крім того, останні версії Visual Studio мають опції для більш розширених оптимізацій, таких як оптимізація часу зв'язку та оптимізація за профілем.