Как настроить компилятор в visual studio на оптимизацию скорости выполнения кода на c
имя опции говорит что-то, но что Visual Studio/compiler действительно делают и каковы реальные последствия?
Edit: если вы ищете google, вы можете найти этот адрес, но это не совсем то, что я ищу. Интересно, что происходит на самом деле. Например, почему петли получают меньше времени и т. д.
без оптимизации компилятор создает очень тупой код - каждая команда компилируется очень просто, так что она делает то, что задумано. В отладочных сборках оптимизация по умолчанию отключена, поскольку без оптимизации созданный исполняемый файл соответствует исходному коду простым способом.
переменные, хранящиеся в регистрах
после включения оптимизации компилятор применяет множество различных методов для создания кода бежать быстрее, но делать то же самое. Наиболее очевидным различием между оптимизированными и неоптимизированными сборками в Visual C++ является тот факт, что значения переменных хранятся в регистрах как можно дольше в оптимизированных сборках, в то время как без оптимизации они всегда хранятся в памяти. Это влияет не только на скорость кода, но и на отладку. В результате такой оптимизации отладчик не может достоверно получить значение переменной при прохождении код.
другие оптимизации
есть несколько других оптимизаций, применяемых компилятором, как описано в /o параметры (оптимизация кода) MSDN docs. Общее описание различных методов оптимизации см. статья оптимизации компилятора Википедии.
Он удаляет любые инструкции NOP, которые мы в противном случае испустили бы, чтобы помочь в отладке. Когда оптимизация выключена (и отладочная информация включена), компилятор выдаст инструкции NOP для строк, которые не имеют никакого фактического IL, связанного с ними, но которые вы можете захотеть поставить точку останова. Наиболее распространенным примером чего - то подобного будет "конец If" оператора "If" - нет фактического IL испускается для конца If, поэтому мы не испускаем NOP, отладчик не позволит вам установить точку останова на нем. Включение оптимизации заставляет компилятор не испускать NOPs.
мы делаем простой базовый анализ блоков сгенерированного IL для удаления любых мертвых блоков кода. То есть мы разбиваем каждый метод на блоки IL, разделенные инструкциями ветви. Проведя быстрый анализ того, как блоки взаимодействуют, мы можем идентифицировать любые блоки, которые не имеют ветвей в них. Таким образом, мы можем выяснить блоки кода, которые никогда не будут выполняться и могут быть опущены, что делает сборку немного меньше. На этом этапе мы также делаем некоторые незначительные оптимизации ветвей - например, если вы получили еще один оператор GoTo, мы просто оптимизируем первый GoTo, чтобы перейти к цели второго GoTo.
мы выдаем DebuggableAttribute с IsJITOptimizerDisabled значение False. В принципе, это позволяет JIT во время выполнения оптимизировать код, как он считает нужным, в том числе переупорядочивание и вставка кода. Это приведет к более эффективному и меньшему коду, но это означает, что попытка отладки кода может быть очень сложной (как скажет вам любой, кто попробовал). Фактический список оптимизаций JIT-это то, что я не знаю - может быть, кто-то вроде Криса Брумма в какой-то момент вмешается в это. Короче говоря, переключатель оптимизации включает оптимизации, которые могут сделать установку точек останова и шаг через ваш код посильнее.
короткий ответ: используйте -Ox и позвольте компилятору выполнять свою работу.
длинный ответ: эффект различных видов оптимизации невозможно точно предсказать. Иногда оптимизация для быстрого кода фактически дает меньший код, чем при оптимизации по размеру. Если вы действительно хотите получить последние 0,01% производительности (speedwise или sizewise), вам нужно проверить различные комбинации опций.
кроме того, в последних версиях Visual Studio есть опции для более продвинутые оптимизации, такие как оптимизация времени связи и профильная оптимизация.
Какие есть методы оптимизации программ по скорости выполнения кода? То есть, чтобы код выполнялся как можно быстрее.
Пишите здесь свои советы (желательно с объяснением, что да как).
Какие самые долгие, ресурсоемкие (для ЦП) операции и чем их можно заменить?
Какие типы данных обрабатываются быстрее всего, какие медленнее?
Ощутима ли разница (по скорости) при использвании short и int, int и unsigned?
А также советуйте литературу по оптимизации. Может знаете какую-нибудь хорошую книжку, где про это было бы много и качественно написано?
В программировании я использую компилятор MS Visual C++ 2008 (если это имеет значение).
P.S. вот недавно услышал такое: "везде, где это возможно, лучше использовать обычные массивы
так как это довольно ресурсоемкая операция". Правда ли это?
И ещё: постфиксный/префиксный инкремент - какой лучше использовать в повседневности?
Говорят ++x эффективнее, чем x++. Правда что ли?
Помощь в написании контрольных, курсовых и дипломных работ здесь
Оптимизация скорости
Есть массив порядка 300000 элементов из структур типа struct Data < short value1; bool.
Оптимизация цикла по скорости
Помогите пожалуйста оптимизировать данный цикл (изменить его, чтобы он выполнялся быстрее): .
Оптимизация скорости выполнения
Нахожусь в процессе написания проги для определения СЕО-параметров сайта. Программа разбита на.
Выделение же памяти в стеке происходит мгновенно
а статические массивы так вообще заранее выделены.
Но другой вопрос - насколько это скажется на скорости.
А вообще тема очень обширная.
Интересная тема.
Послушаю гуру.
Как говорится - чем ниже уровень языка - тем точнее и быстрее выполняется код.
Я это к тому, что компиляторы частенько много действительно лишнего кода вставляют. _Hellboy, учтите, для этого надо хорошо знать асм, иначе такая "оптимизация" может работать намного дольше, чем если бы все было на С/С++ Безусловно. Но необязательно "на отлично", нужно просто знать, что из себя представляет стэк, как его чистить и знать команды для работы с регистрами процессора. Ах да, для использования ассемблера в Си на полную мощь, нужно ещё знать основные основные соглашения о вызове функций (stdcall, cdecl, fastcall, thiscall и т.д.). Думаю, этого вполне достаточно.
Решение
Какие есть методы оптимизации программ по скорости выполнения кода? То есть, чтобы код выполнялся как можно быстрее. 1. Выбрать правильный и эффективный алгоритм. Учти, что высокоуровневая (алгоритмическая) оптимизация гораздо эффективнее низкоуровневой - всяких там вставок на ассемблере и тому подобного.2. Написать правильную программу и убедиться в правильной ее работе. Пойми, что правильную программу можно сделать быстрой. Но вот быструю, но неправильную - гораздо труднее сделать правильной.
3. Использовать профилировщик и оптимизировать по скорости выполнения не всю программу подряд, а только критические участки. Оптимизация только 10% кода программы дает прирост 90% в производительности. Задача в том, чтобы найти именно эти 10%, а не распылять силы по всему коду. Здесь нужно использовать правильный инструмент - профилировщик (profiler).
CheshireCat в первом пункте своего тезиса написал самую главную мысль: плохо организованная программа работать будет медленно, хоть ты десять раз её на ассемблере напиши. Да и в большинстве случаев окажется так, что код написанный на си будет работать быстрее самодельного ассемблерного кода. Потому что компилятор лучше знает тонкости планирования команд, чем программист
Добавлено через 4 минуты
Какие типы данных обрабатываются быстрее всего, какие медленнее?
Ощутима ли разница (по скорости) при использвании short и int, int и unsigned?
А также советуйте литературу по оптимизации. Может знаете какую-нибудь хорошую книжку, где про это было бы много и качественно написано? Вообще, нормальный компилятор в таких вопросах как правило сам вместо тебя сделает то, что нужно
Решение
Для втроенных типов - нет. Для пользовательских - да, т.к. постинкремент сопровождается созданием копии объекта, хранящего старое состояние, и возвратом его по значению. Да и в большинстве случаев окажется так, что код написанный на си будет работать быстрее самодельного ассемблерного кода. Потому что компилятор лучше знает тонкости планирования команд, чем программистНе согласен. Во время анализа своих программ при помощи дизассемблера я часто вижу случаи, когда в функциях используются ненужные пересылки, допустим:
Это взято из моей программы, написанной на VC++ 2008. И это далеко не единичный случай, иногда доходит до абсурда.1) Какие есть методы оптимизации программ по скорости выполнения кода? То есть, чтобы код выполнялся как можно быстрее.
2) Какие самые долгие, ресурсоемкие (для ЦП) операции и чем их можно заменить?
3) Какие типы данных обрабатываются быстрее всего, какие медленнее?
Ощутима ли разница (по скорости) при использвании short и int, int и unsigned?
4) А также советуйте литературу по оптимизации. Может знаете какую-нибудь хорошую книжку, где про это было бы много и качественно написано?
5) P.S. вот недавно услышал такое: "везде, где это возможно, лучше использовать обычные массивы
так как это довольно ресурсоемкая операция". Правда ли это?
6) И ещё: постфиксный/префиксный инкремент - какой лучше использовать в повседневности?
Говорят ++x эффективнее, чем x++. Правда что ли?
2. Квадратный корень. Возведение в степень. Заменяется логарифмами. Обращение к диску. Заменяется предварительной загрузкой. Там много всякого. Надо смотреть по месту.
3. Чем больше байт - тем дольше обрабатывается. По собственному опыту могу сказать, что ощутимой разницы между float и long нет, а между long и char - есть. Особенно это проявляется при работе с большими массивами данных (типа матриц 1000х1000 элементов).
4. Главные принципы оптимизации - это найти то место, которое тормозит процесс. Как правило, во всей программе таких мест не много и они составляют менее 2% кода. После того, как эти места найдены, нужно исключить оттуда лишние вычисления и применить все возможные методы оптимизации. Те места, которые не оказывают влияния на быстродействие, оптимизировать не надо. Даже наоборот, в те участки программы, которые и так быстро выполняются, нужно перенести часть вычислений из критических областей.
5. Бессовестно врут. Нет никакой разницы, делаешь ли ты new или используешь массив. Главное, чтобы ты не делал new и delete в цикле по 100 раз в секунду. Логика тут проста. В большинстве случаев резервирование памяти происходит до вычислений. Если у тебя new выполняется, например, 2 миллисекунды, а после этого идет 2-секундный вычислительный процесс, то этого new никто не заметит. И даже если ты заменишь его на статический массив, то заметного прироста быстродействия не будет. New и delete использовать можно и нужно. Просто нужно думать, где это делать надо, а где - нет. Если в программе нужно часто резервировать память, то лучшим решением будет вычислить максимальный возможный объем и за резервировать его с помощью того же New в самом начале работы. Потом эту память нужно использовать как хочешь и по окончании работы освободить.
Что же касается твоего примера с char * x = new char [100], то это конкретно эта строчка - большая тупость. New используется, когда размер неизвестен. Вот так более кошерно:
6. Это уже буквоедство. Когда человек не знает, как существенно оптимизировать код, он начинает переставлять буковки. Потом выясняется, что 1+2 работает быстрее, чем 2+1. Ура! На самом же деле, операционная система постоянно выполняет что-то в фоновом режиме. И, если в момент замера скорости произойдет активация фонового процесса, то таймер покажет на 2 микросекунды больше, чем надо. И из этого люди делают далеко идущие выводы (я делал, во всяком случае )
Добавлено через 14 минут
Как говорится - чем ниже уровень языка - тем точнее и быстрее выполняется код.
Я это к тому, что компиляторы частенько много действительно лишнего кода вставляют.
Не факт. У меня уже был случай в моей собственной практике. Написал часть кода не только на ассемблере, но и с использованием MMX, который позволяет выполнять до 4 инструкций одновременно. Казалось бы, вот оно - быстродействие. Но нет, стало только медленнее. А причина была в том, что я тратил слишком много времени на подготовку данных для этого MMX-а (это диктовалось особенностью алгоритма). Пока их из массива выгрузишь, пока отсортируешь, пока загрузишь в регистры - быстрее классическим C++ посчитать.
Сразу скажу, что в финале мне удалось добиться сокращения времени компиляции решения с 4:24 минут до менее чем одной минуты. Детали под катом.
На старт!
В начале я собирался собрать отдельную тестовую машину с «чистой» ОС и одной лишь установленной программой — Visual Studio. Но потом решил, что тестировать сферических коней в вакууме будет не совсем верно. На компьютере программиста так или иначе будут установлены какой-нибудь браузер, антивирус, файловый менеджер, архиватор, текстовый редактор и т.д., а значит Студии придется работать со всем этим по близости. Значит, в таком режиме и будем её тестировать, на обычном компьютере разработчика (переустановив, правда, ради чистоты эксперимента, операционную систему и поставив свежие версии используемых в работе программ).
Набор экспериментов составлен по советом с сайтов Stackoverfow, RSDN, форумов MSDN, выдачи Google ну и просто из головы.
Объектом тестирования станет время полной компиляции решения. Перед каждым экспериментом вся папка проекта будет удаляться, код будет заново заливаться из репозитория, а Visual Studio перезагружаться. Каждый эксперимент будет повторяться трижды, результатом будет среднее время. После каждого эксперимента сделанные изменения откатываются.
Если кому-нибудь интересна аппаратная конфигурация моего компьютера, так вот она:
+ жесткий диск WD 500 Гб, 7200 RPM, 16 Мб кэш
+ Win 7 Профессиональная 32 бита со всеми возможными обновлениями
+ Visual Studio 2010 Professional с первым сервис-паком
В Windows включен режим максимальной производительности, отключен Aero и всякие анимации.
Исходное время компиляции моего решения: 4 минуты 24 секунды
Поехали!
Временные файлы — на RamDrive
Есть мнение, что самые медленные операции во время компиляции решения связаны с доступом к диску. Уменьшить это время можно путем использования RamDrive для временных файлов.
Результат: 4 минуты 13 секунд или -4.17% ко времени компиляции.
Вывод: прирост производительности имеется, хоть и небольшой. Если количество ОЗУ позволяет, этот совет можно применять в деле.
Весь проект — на RamDrive
Коль уж нам удалось немного ускорить компиляцию за счет выноса на RamDrive временных файлов, возможно получиться добиться еще лучших результатов, переместив туда всё решение (всё-таки более 4000 файлов).
Результат: 3 минуты 47 секунд или -14.02% ко времени компиляции.
Вывод: По началу этот эксперимент показался мне немного стрёмным — хранить исходники в оперативной памяти не лучший вариант (а вдруг пропадет питание?). Но, учитывая факт наличия бесперебойников, равно как и таких версий RamDrive, как от QSoft (с автоматическим дублированием измененных файлов с RamDrive на жесткий диск) убедили меня, что вариан возможен. Нужно только достаточно ОЗУ (и, по-хорошему, 64-битная ОС).
Весь проект — на флешку
Включение функции ReadyBoost в Windows
Microsoft расхваливает эту функцию именно за повышение производительности при работе с большим количеством относительно небольших блоков данных (наш вариант). Попробуем.
Результат: 4 минуты 17 секунд или -2.65% ко времени компиляции.
Вывод: вполне нормальный способ ускорения работы. Кроме необходимости 1 раз вставить флешку и настроить ReadyBoost других недостатков не имеет, а некоторый прирост производительности даёт.
Изменение количества одновременно компилирующихся проектов
Visual Studio при установке прописывает это число равным общему количеству ядер процессоров в Вашем ПК. Тем не менее, мы можем попробовать его изменить (делается это в настройках VS для С++ проектов) и оценить изменение производительности. Так как в моём компьютере 4-ядерный процессор, изначально это число было равным четырём.
Результат:
6 проектов компилируются одновременно — 4 минуты 34 секунды или +3.79% ко времени компиляции
2 проекта компилируется одновременно — 4 минуты 21 секунда или -1.14% ко времени компиляции
Вывод: я с самого начала ожидал, что увеличение числа одновременно компилирующихся проектов не даст никакого прироста производительности (так и вышло). Но вот почему уменьшение его до двух дало небольшой прирост для меня не очень понятно. Возможно, это просто статистическая погрешность, а может быть при компиляции 4-ех проектов Студия из-за их зависимостей теряет время на каком-то ожидании, что происходит реже при компиляции всего двух проектов. Если у кого-нибудь еще есть мысли по теме — прошу в комментарии.
Отключение вывода текста билда в окно Оutput
Меньше вывода текста при компиляции — быстрее результат.
Результат: 4 минуты 22 секунды или -0.76% ко времени компиляции
Вывод: прирост столь смехотворен, что не стоит даже комментариев. Он может быть как реальным, так и случайным.
Очистка корзины
Я вычитал этот совет на Stackoverflow. Аргументация была в том, что по ходу компиляции создаётся и удаляется масса мелких файлов, а процедура удаления в Windows работает медленнее при забитой корзине. Поскольку все предыдущие эксперименты я и так проводил при пустой корзине, мне пришлось проделать обратный эксперимент — положить в корзину 5000 файлов общим объёмом в 2 Гб.
Результат: 4 минуты 23 секунды или +0.38% ко времени компиляции.
Вывод: время компиляции осталось без изменений. Теория провалилась.
Ключ компилятора /MP
Ключ /MP — это тоже параллельная компиляция, но уже не проектов в решении, а файлов внутри каждого проекта.
Результат: 2 минуты 38 секунд или -40.15% ко времени компиляции
Вывод: это одно из самых существенных достижений среди всех поставленных экспериментов. Конечно, прирост столь высок в основном из-за 4-ядерности моего процессора, но вскоре такие (и еще более-ядерные процессоры) станут нормой в любом компьютере, так что включать опцию имеет смысл. При её включении компилятор честно предупреждает, что она не совместимо с ключом /Gm (Enable Minimal Rebuild), что вначале пугает — возникает мысль, что теперь при любом изменении любого файла будет происходить полная перекомпиляция решения. Так вот — нифига подобного! После изменения одного файла с кодом, как и ранее, будет перекомпилироваться только этот файл, а не всё решение. Всё, что делает ключ — это определяет выбор алгоритма определения взаимосвязей файлов кода и файлов заголовков в проекте (детальнее). Оба алгоритма неплохи и существенный прирост производительности от включения /MP во много раз превосходит недостатки от отключения /Gm.
Удаление папки решения из индекса поиска Windows
Есть мнение, что изменение файлов в папках, которые индексируются механизмом поиска ОС Windows, приводит к увеличению времени компиляции.
Результат: 4 минуты 24 секунды или никакого изменения во времени компиляции
Вывод: то ли индексирование в Windows сделано так хорошо, что вообще не замедляет работу других программ с диском, то ли это влияние минимально, то ли мне просто повезло и компиляция не совпала по времени с индексацией.
Unity Builds
Об этом механизме я рассказывал в прошлой статье.
Результат: 3 минуты 24 секунды или -22.73% ко времени компиляции.
Вывод: сокращение времени компиляции существенно. О всех достоинства и недостатках этой методики я уже писал, использовать его или нет Вы можете решить сами.
Завершение лишних программ
Работающие параллельно со Студией программы кушают память и ресурсы процессора. Их закрытие может положительно сказаться на скорости работы Студии. Итак, я закрываю Skype, QIP, Dropbox, GTalk, DownloadMaster, Mysql server.
Результат: 4 минуты 15 секунд или -3.41% ко времени компиляции
Вывод: во время компиляции придется обойтись без других программ. Никаких анекдотов и порнухи «пока оно там компилится». Вряд ли полный отказ от всех программ возможен для разработчика, но можно создать бат-файлы, включающие\выключащие все лишнее и иногда ими пользоваться.
Отключение антивируса
Если у Вас в системе установлен антивирус, то эта сволочь полезная программа постоянно проверяет все файловые операции. Таким образом, каждый участвующей в компиляции файл будет удостоен внимательного взгляда бдительного стража, что может замедлить время компиляции. Я, честно говоря, не был уверен, как настроить мой антивирус так, чтобы быть уверенным в полном игнорировании им моего проекта и попросту его удалил. Ваш антивирус, возможно, конфигурируется нужным образом.
Результат: 3 минуты 32 секунды или -19.07% ко времени компиляции
Вывод: удивительный результат. Я почему-то был уверен, что все эти *.cpp. *.h, *.obj файлы полностью антивирусом игнорируются и внимания удостоятся только скомпилированные исполняемые программы, что не очень сильно замедлит работу. Однако, факт налицо — почти минута времени экономии.
Дефрагментация жесткого диска
Файловые операции выполняются быстрее на дефрагментированом диске, а компиляция — это огромное количество файловых операций. Я специально оставил этот эксперимент напоследок, поскольку отменить дефрагментацию диска невозможно, а я хотел сделать эксперименты максимально независимыми.
Результат: 4 минуты 8 секунд или -6.06% ко времени компиляции
Вывод: практика согласуется с теорией. Поставьте себе дефрагментацию в планировщик и почаще.
Способы, которые, вероятно, помогли бы, но попробовать не вышло
Переход на 64-битную версию Windows
Есть предположение, что это дало бы некоторый прирост производительности, но портирование нашего проекта под x64, в силу его специфики, имеет не очень высокий приоритет и пока не реализовано. Соответственно, пока что нечего и тестировать.
Обновление процессора, памяти, замена HDD на SSD или RAID
Нужно сказать, что моя тестовая машинка не так уж плоха и до планового апгрейда еще далеко. Работаем с тем, что есть. По отзывам в интернете наибольшее влияние на время компиляции оказывает установка SSD.
Вынесение редко меняющихся проектов в отдельное решение
Это и так уже было сделано. Если в Вашем проекте подобное еще не реализовано — обязательно займитесь.
Xoreax's IncrediBuild или аналог
Распределение компиляции между компьютерами — это уже достаточно кардинальный шаг. Он требует покупки специального ПО, серьёзной настройки и некоторого «выворачивания наизнанку» процесса сборки. Но в очень больших проектах это может стать единственным возможным вариантом. На сайте Xoreax's IncrediBuild есть данные по приросту производительности, рассказы клиентов и куча другого спама разной полезной информации по теме.
Это всё, что я хотел рассказать о способах ускорения компиляции решений в Visual Studio, а в следующей статье я приведу несколько советов по ускорению работы самой IDE.
Имя опции говорит что-то, но что Visual Studio/компилятор действительно делает и каковы реальные последствия?
Изменить: если вы ищете google, вы можете найти этот адрес, но на самом деле я не ищу. Интересно, что происходит. Например, почему циклы получают меньше времени и т.д.
ОТВЕТЫ
Ответ 1
Без оптимизации компилятор создает очень тупой код - каждая команда компилируется очень простым способом, так что она выполняет предназначенную задачу. В сборках отладки оптимизации отключены по умолчанию, поскольку без оптимизаций созданный исполняемый файл напрямую соответствует исходному коду.
Переменные хранятся в регистрах
Как только вы включаете оптимизацию, компилятор применяет множество различных методов, чтобы заставить код работать быстрее, в то же время делая то же самое. Наиболее очевидное различие между оптимизированными и неоптимизированными сборками в Visual C++ заключается в том, что значения переменных хранятся в регистрах как можно дольше в оптимизированных сборках, в то время как без оптимизации они всегда сохраняются в памяти. Это влияет не только на скорость кода, но и на отладку. В результате этой оптимизации отладчик не может надежно получить значение переменной во время выполнения кода.
Другие оптимизации
Существует несколько других оптимизаций, применяемых компилятором, как описано в документах MSDN "Параметры/O (Оптимизировать код)". Для общего описания различных методов оптимизации см. Статью Wikipedia Compiler Optimization.
Ответ 2
Он удаляет все инструкции NOP, которые в противном случае мы могли бы использовать, чтобы помочь в отладке. Когда оптимизация отключена (и включена информация об отладке), компилятор будет выдавать инструкции NOP для строк, у которых нет фактического ИЛ, связанного с ними, но который вы можете захотеть включить точку останова. Наиболее распространенным примером чего-то подобного будет "End If" оператора "If" - там нет реального IL, испускаемого для End If, поэтому мы не выдаем NOP, отладчик не позволит вам установить точку останова в теме. Включение оптимизации заставляет компилятор не выделять NOP.
Мы выполняем простой базовый блок-анализ генерируемого IL для удаления блоков мертвого кода. То есть мы разрываем каждый метод на блоки IL, разделенные инструкциями ветвления. Проводя быстрый анализ того, как блоки взаимосвязаны, мы можем идентифицировать любые блоки, в которых нет ветвей. Таким образом, мы можем вычислить блоки кода, которые никогда не будут выполнены и могут быть опущены, что делает сборку немного меньшей. На данный момент мы также выполняем некоторые небольшие оптимизации ветвей - например, если вы GoTo другой оператор GoTo, мы просто оптимизируем первый GoTo для перехода к второй цели GoTo.
Мы выделяем атрибут DebuggableAttribute с параметром IsJITOptimizerDisabled, равным False. В принципе, это позволяет JIT времени выполнения оптимизировать код, как он считает нужным, включая переупорядочивание и встраивание кода. Это приведет к созданию более эффективного и меньшего кода, но это означает, что попытка отладки кода может быть очень сложной (как кто-нибудь, кто попробовал это, скажет вам). Фактический список того, что оптимизация JIT - это то, чего я не знаю, может быть, кто-то вроде Криса Брумме в какой-то момент перезвонит. Длинным и, тем не менее, является то, что оптимизационный коммутатор позволяет оптимизировать, что может сделать установку контрольных точек и более сложную работу над вашим кодом.
Ответ 3
Короткий ответ: use -Ox и пусть компилятор выполнит свою работу.
Длинный ответ: эффект разного рода оптимизаций невозможно точно предсказать. Иногда оптимизация для быстрого кода фактически дает меньший код, чем при оптимизации размера. Если вы действительно хотите получить последние 0,01% производительности (по скорости или по силе), вам нужно сравнить различные комбинации параметров.
Кроме того, в последних версиях Visual Studio есть опции для более продвинутых оптимизаций, таких как оптимизация времени соединения и оптимизация с помощью профиля.
Читайте также: