Войти
В информатике, оптимизация программы или оптимизация программного обеспечения представляет собой процесс модификации программной системы, чтобы заставить ее работать более эффективно или использовать меньше ресурсов. В общем, компьютерная программа может быть оптимизирована так, чтобы она выполнялась быстрее, или чтобы она могла работать с меньшим объемом памяти памяти или другими ресурсами, или потреблять меньше энергии.
Хотя слово «оптимизация» имеет тот же корень, что и «оптимальный» ", процесс оптимизации редко приводит к созданию действительно оптимальной системы. Как правило, систему можно сделать оптимальной не в абсолютном выражении, а только в отношении данной метрики качества, которая может контрастировать с другими возможными метриками. В результате оптимизированная система обычно будет оптимальной только для одного приложения или для одной аудитории. Можно сократить время, которое программа тратит на выполнение некоторой задачи, за счет увеличения потребления памяти. В приложении, где объем памяти ограничен, можно сознательно выбрать более медленный алгоритм , чтобы использовать меньше памяти. Часто не существует универсального дизайна, который бы хорошо работал во всех случаях, поэтому инженеры идут на компромиссы для оптимизации наиболее интересных атрибутов. Кроме того, усилия, необходимые для того, чтобы сделать часть программного обеспечения полностью оптимальной - неспособной к дальнейшим улучшениям - почти всегда превышают разумные пределы получаемых выгод; поэтому процесс оптимизации может быть остановлен до того, как будет достигнуто полностью оптимальное решение. К счастью, часто самые большие улучшения происходят на ранних этапах процесса.
Даже для заданной метрики качества (например, скорости выполнения) большинство методов оптимизации только улучшают результат; они не претендуют на получение оптимального результата. Супероптимизация - это процесс поиска действительно оптимального результата.
Оптимизация может происходить на нескольких уровнях. Обычно более высокие уровни оказывают большее влияние, и их труднее изменить в дальнейшем в проекте, что требует значительных изменений или полной переписывания, если их нужно изменить. Таким образом, оптимизация, как правило, может продолжаться путем уточнения от более высокого к низкому, при этом начальный выигрыш будет больше и достигается меньшими затратами, а последующий выигрыш будет меньше и требует большей работы. Однако в некоторых случаях общая производительность зависит от производительности очень низкоуровневых частей программы, и небольшие изменения на поздней стадии или раннее рассмотрение низкоуровневых деталей могут иметь огромное влияние. Обычно на протяжении всего проекта некоторое внимание уделяется эффективности - хотя она значительно варьируется, - но серьезная оптимизация часто считается доработкой, которую нужно делать поздно, если вообще когда-либо. В долгосрочных проектах обычно есть циклы оптимизации, когда улучшение одной области выявляет ограничения в другой, и они обычно сокращаются, когда производительность становится приемлемой или выгоды становятся слишком маленькими или дорогостоящими.
Поскольку производительность является частью спецификации программы - программа, которая работает необычно медленно, не подходит для этой цели: видеоигра с частотой 60 Гц (кадров в секунду) приемлема, но 6 кадров в секунду. -второй является недопустимо изменчивым - производительность является предметом рассмотрения с самого начала, чтобы гарантировать, что система способна обеспечить достаточную производительность, а ранние прототипы должны иметь примерно приемлемую производительность, чтобы была уверенность в том, что конечная система (с оптимизацией) достигнет приемлемая производительность. Иногда это опускается, полагая, что оптимизацию всегда можно провести позже, в результате чего прототипные системы работают слишком медленно - часто на порядок или более - и системы, которые в конечном итоге являются отказами, потому что они не могут достичь своих целей производительности, таких как Intel 432 (1981); или те, которые требуют годы работы для достижения приемлемой производительности, например Java (1995), которая достигла приемлемой производительности только с HotSpot (1999). Степень изменения производительности между прототипом и производственной системой и то, насколько она поддается оптимизации, может быть значительным источником неопределенности и риска.
На самом высоком уровне дизайн может быть оптимизирован для наилучшего использования доступных ресурсов с учетом целей, ограничений и ожидаемого использования / нагрузки. Архитектурный дизайн системы в значительной степени влияет на ее производительность. Например, система с привязкой к сетевой задержке (где сетевая задержка является основным ограничением для общей производительности) должна быть оптимизирована для минимизации сетевых отключений, в идеале выполняя один запрос (или без запросов, как в протоколе push ), а не несколько обходов. Выбор дизайна зависит от целей: при разработке компилятора, если быстрая компиляция является ключевым приоритетом, однопроходный компилятор быстрее, чем многопроходный компилятор (предполагая ту же работу), но если целью является скорость вывода кода, более медленный многопроходный компилятор выполняет задачу лучше, даже если он сам занимает больше времени. Выбор платформы и языка программирования происходит на этом уровне, и их изменение часто требует полной перезаписи, хотя модульная система может допускать перезапись только некоторых компонентов - например, программа Python может перезаписывать критические для производительности разделы на C. системы, выбор архитектуры (клиент-сервер, одноранговая и т. д.) происходит на уровне проекта, и его может быть трудно изменить, особенно если все компоненты не могут быть заменены синхронно (например, старые клиенты).
Учитывая общий дизайн, хороший выбор эффективных алгоритмов и структур данных, а также эффективную реализацию этих алгоритмов и Далее следуют структуры данных. После проектирования выбор алгоритмов и структур данных влияет на эффективность больше, чем любой другой аспект программы. Как правило, структуры данных сложнее изменить, чем алгоритмы, поскольку предположение о структуре данных и предположения о ее производительности используются во всей программе, хотя это можно минимизировать, используя абстрактные типы данных в определениях функций и сохраняя конкретные определения структур данных ограничены несколькими местами.
Для алгоритмов это в первую очередь заключается в обеспечении того, чтобы алгоритмы были постоянными O (1), логарифмическими O (log n), линейными O (n) или в некоторых случаях логарифмическими O (n log n) в вход (как в пространстве, так и во времени). Алгоритмы с квадратичной сложностью O (n) не масштабируются, и даже линейные алгоритмы вызывают проблемы при повторном вызове и обычно заменяются постоянными или логарифмическими, если это возможно.
Помимо асимптотического порядка роста, постоянные факторы имеют значение: асимптотически более медленный алгоритм может быть быстрее или меньше (потому что проще), чем асимптотически более быстрый алгоритм, когда они оба сталкиваются с небольшими входными данными, что может быть в том случае, если происходит в реальности. Часто гибридный алгоритм обеспечивает лучшую производительность из-за того, что этот компромисс меняется с размером.
Общий метод повышения производительности - избегать работы. Хорошим примером является использование fast path для общих случаев, повышающее производительность за счет исключения ненужной работы. Например, при использовании простого алгоритма компоновки текста для латинского текста, переключение на сложный алгоритм компоновки только для сложных скриптов, таких как Деванагари. Другой важный метод - это кэширование, в частности мемоизация, позволяющее избежать избыточных вычислений. Из-за важности кэширования в системе часто бывает много уровней кэширования, что может вызвать проблемы из-за использования памяти и проблемы с корректностью из-за устаревших кешей.
Помимо общих алгоритмов и их реализации на абстрактной машине, выбор конкретного уровня исходного кода может иметь большое значение. Например, в ранних компиляторах C while (1)был медленнее, чем for (;;)для безусловного цикла, потому что while (1)оценил 1 а затем имелся условный переход, который проверял, было ли оно истинным, в то время как для (;;)имел безусловный переход. Некоторые оптимизации (например, эта) в настоящее время могут выполняться оптимизирующими компиляторами. Это зависит от исходного языка, целевого машинного языка и компилятора и может быть трудным для понимания или прогнозирования и может меняться со временем; это ключевое место, где понимание компиляторов и машинного кода может улучшить производительность. Перемещение кода с инвариантным циклом и оптимизация возвращаемого значения являются примерами оптимизаций, которые уменьшают потребность во вспомогательных переменных и могут даже привести к более высокой производительности за счет исключения циклических оптимизаций.
Между уровнем исходного кода и уровнем компиляции директивы и флаги сборки могут использоваться для настройки параметров производительности в исходном коде и компиляторе. соответственно, например, использование препроцессора определяет отключение ненужных программных функций, оптимизацию для конкретных моделей процессоров или аппаратных возможностей или прогнозирование ветвления, например. Системы распространения программного обеспечения на основе исходного кода, такие как BSD Ports и Gentoo Portage, могут использовать преимущества этой формы оптимизации.
Использование оптимизирующего компилятора стремится гарантировать, что исполняемая программа оптимизирована, по крайней мере, настолько, насколько компилятор может предсказать.
На самом низком уровне написание кода с использованием языка ассемблера, разработанного для конкретной аппаратной платформы, может дать наиболее эффективный и компактный код, если программист преимущество полного репертуара машинных инструкций. По этой причине многие операционные системы, используемые во встроенных системах, традиционно писались на ассемблере. Программы (кроме очень маленьких) редко пишутся от начала до конца в сборке из-за затрат времени и средств. Большинство из них скомпилировано с языка высокого уровня на ассемблер и оптимизировано вручную оттуда. Когда эффективность и размер менее важны, большие части могут быть написаны на языке высокого уровня.
С более современными оптимизирующими компиляторами и большей сложностью недавних процессоров, сложнее написать более эффективный код, чем тот, который генерирует компилятор, и это требуется немногим проектам. «конечный» шаг оптимизации.
Большая часть написанного сегодня кода предназначена для работы на максимально возможном количестве машин. Как следствие, программисты и компиляторы не всегда используют преимущества более эффективных инструкций, предоставляемых новыми процессорами, или причуд старых моделей. Кроме того, ассемблерный код, настроенный для конкретного процессора без использования таких инструкций, может быть неоптимальным для другого процессора, ожидая другой настройки кода.
Обычно сегодня вместо того, чтобы писать на ассемблере, программисты будут использовать дизассемблер для анализа вывода компилятора и изменения исходного кода высокого уровня, чтобы его можно было скомпилировать более эффективно, или понять, почему это неэффективно.
Компиляторы «точно в срок» могут создавать настраиваемый машинный код на основе данных времени выполнения за счет накладных расходов на компиляцию. Этот метод восходит к самым ранним механизмам регулярных выражений и получил широкое распространение в Java HotSpot и V8 для JavaScript. В некоторых случаях адаптивная оптимизация может выполнять оптимизацию времени выполнения, превышающую возможности статических компиляторов, путем динамической настройки параметров в соответствии с фактическими входными данными или другими факторами.
Профильная оптимизация - это метод оптимизации компиляции с опережением времени (AOT), основанный на профилях времени выполнения, и аналогичен статическому «среднему случаю» аналогу динамического метода адаптивной оптимизации.
Самомодифицирующийся код может изменяться в ответ на условия выполнения, чтобы оптимизировать код; это было более распространено в программах на ассемблере.
Некоторые конструкции ЦП могут выполнять некоторую оптимизацию во время выполнения. Некоторые примеры включают исполнение вне очереди, спекулятивное исполнение, конвейеры команд и предикторы ветвления. Компиляторы могут помочь программе воспользоваться преимуществами этих функций ЦП, например, с помощью планирования инструкций.
Оптимизация кода также может быть в общих чертах классифицирована как платформа - зависимые и платформенно-независимые методы. Хотя последние эффективны на большинстве или на всех платформах, платформенно-зависимые методы используют определенные свойства одной платформы или полагаются на параметры, зависящие от одной платформы или даже от одного процессора. Поэтому может потребоваться написание или создание разных версий одного и того же кода для разных процессоров. Например, в случае оптимизации на уровне компиляции независимые от платформы методы представляют собой общие методы (такие как разворачивание цикла, сокращение вызовов функций, процедуры, эффективные с точки зрения памяти, сокращение условий и т. Д.), Которые влияют на большинство архитектур ЦП аналогичным образом. Отличный пример независимой от платформы оптимизации был показан с внутренним циклом for, где было замечено, что цикл с внутренним циклом for выполняет больше вычислений в единицу времени, чем цикл без него или цикл с внутренним циклом while. Как правило, они служат для уменьшения общей длины пути команды, необходимой для завершения программы, и / или уменьшения общего использования памяти во время процесса. С другой стороны, платформенно-зависимые методы включают в себя планирование инструкций, параллелизм на уровне инструкций, параллелизм на уровне данных, методы оптимизации кэша (т. Е. Параметры, которые различаются между различными платформами), а оптимальное планирование инструкций может быть различным. даже на разных процессорах одной архитектуры.
Вычислительные задачи могут выполняться несколькими способами с разной эффективностью. Более эффективная версия с эквивалентной функциональностью известна как снижение прочности. Например, рассмотрим следующий фрагмент кода C, целью которого является получение суммы всех целых чисел от 1 до N:
int i, sum = 0; for (i = 1; i <= N; ++i) { sum += i; } printf("sum: %d\n", sum);Этот код можно (при условии отсутствия арифметического переполнения ) переписать с использованием математической формулы, например:
int sum = N * (1 + N) / 2; printf ("sum:% d \ n", sum);Оптимизация, иногда выполняемая автоматически оптимизирующим компилятором, заключается в выборе метода (алгоритм ), который является более эффективным с вычислительной точки зрения при сохранении та же функциональность. См. алгоритмическая эффективность для обсуждения некоторых из этих методов. Однако значительного улучшения производительности часто можно добиться, удалив посторонние функции.
Оптимизация не всегда очевидна или интуитивно понятный процесс. В приведенном выше примере «оптимизированная» версия могла бы фактически быть медленнее, чем исходная версия, если бы Nбыло достаточно маленьким, а конкретное оборудование оказалось намного быстрее при выполнении сложения и цикла операций, чем умножение и деление.
Однако в некоторых случаях оптимизация зависит от n использование более сложных алгоритмов, использование «особых случаев» и специальных «приемов» и выполнение сложных компромиссов. «Полностью оптимизированная» программа может быть более сложной для понимания и, следовательно, может содержать больше ошибок, чем неоптимизированные версии. Помимо устранения очевидных антипаттернов, некоторые оптимизации на уровне кода снижают ремонтопригодность.
Оптимизация обычно сосредоточена на улучшении только одного или двух аспектов производительности: времени выполнения, использования памяти, дискового пространства, пропускной способности, энергопотребления или некоторых других ресурсов. Обычно это требует компромисса - когда один фактор оптимизируется за счет других. Например, увеличение размера кэша улучшает производительность во время выполнения, но также увеличивает потребление памяти. Другие общие компромиссы включают ясность и краткость кода.
Бывают случаи, когда программист, выполняющий оптимизацию, должен решить улучшить программное обеспечение для некоторых операций, но за счет снижения эффективности других операций. Эти компромиссы могут иногда носить нетехнический характер - например, когда конкурент опубликовал результат эталонного теста, который необходимо превзойти для повышения коммерческого успеха, но, возможно, связан с бременем нормального использования. программного обеспечения менее эффективно. Такие изменения иногда в шутку называют пессимизациями.
Оптимизация может включать в себя поиск узких мест в системе - компонента, который является ограничивающим фактором производительности. С точки зрения кода, это часто будет горячая точка - критическая часть кода, которая является основным потребителем необходимого ресурса - хотя это может быть и другой фактор, например, задержка ввода-вывода или сеть. пропускная способность.
В информатике потребление ресурсов часто следует форме степенного закона распределения, и принцип Парето может применяться к оптимизации ресурсов, если учесть, что 80% ресурсы обычно используются в 20% операций. В разработке программного обеспечения часто бывает лучшим приближением, что 90% времени выполнения компьютерной программы тратится на выполнение 10% кода (в этом контексте известный как закон 90/10).
Более сложные алгоритмы и структуры данных хорошо работают со многими элементами, тогда как простые алгоритмы больше подходят для небольших объемов данных - настройка, время инициализации и постоянные коэффициенты более сложного алгоритма могут перевесить выгоду, и таким образом, гибридный алгоритм или адаптивный алгоритм может быть быстрее любого отдельного алгоритма. Профилировщик производительности может использоваться, чтобы сузить круг решений о том, какие функции соответствуют каким условиям.
В некоторых случаях добавление дополнительной памяти может помочь ускорить выполнение программы. Например, программа фильтрации обычно считывает каждую строку, фильтрует и немедленно выводит эту строку. Это использует достаточно памяти только для одной строки, но производительность, как правило, низкая из-за задержки каждого чтения с диска. Кэширование результата также эффективно, хотя также требует большего использования памяти.
Оптимизация может снизить читаемость и добавить код, который используется только для повышения производительности. Это может усложнить программы или системы, затрудняя их обслуживание и отладку. В результате оптимизация или настройка производительности часто выполняется в конце стадии разработки..
Дональд Кнут сделал следующие два заявления об оптимизации:
«Мы должны забыть о небольшой эффективности, скажем о 97% случаев: преждевременная оптимизация - корень всего зла. Тем не менее, мы не должны упускать наши возможности в этих критических 3% »
«В общепринятых инженерных дисциплинах легко достижимое улучшение на 12% никогда не считается незначительным, и я считаю, что такая же точка зрения должна преобладать в разработке программного обеспечения»
«Преждевременная оптимизация» - это фраза, используемая для описания ситуации, когда программист позволяет соображениям производительности влиять на дизайн фрагмента кода. Это может привести к тому, что дизайн будет не таким чистым, как мог бы, или код неправильный, потому что код усложняется оптимизацией, а программист отвлекается на оптимизацию.
При принятии решения об оптимизации определенной части программы всегда следует учитывать Закон Амдала : влияние на всю программу во многом зависит от того, сколько времени фактически затрачено на эту конкретную часть. часть, которая не всегда очевидна при взгляде на код без анализа производительности.
Таким образом, лучший подход состоит в том, чтобы сначала спроектировать код из проекта, а затем профиль / эталонный тест получившийся код, чтобы увидеть, какие части следует оптимизировать. Простой и элегантный дизайн часто легче оптимизировать на этом этапе, а профилирование может выявить неожиданные проблемы с производительностью, которые не были бы решены преждевременной оптимизацией.
На практике часто бывает необходимо помнить о целях производительности при первом проектировании программного обеспечения, но программист балансирует между целями проектирования и оптимизации.
Современные компиляторы и операционные системы настолько эффективны, что запланированное повышение производительности часто не может быть реализовано. Например, кэширование данных на уровне приложения, которые снова кэшируются на уровне операционной системы, не дает улучшений в исполнении. Тем не менее, это редкий случай, когда программист удаляет неудачные оптимизации из производственного кода. Верно также и то, что усовершенствования аппаратного обеспечения чаще всего устраняют любые потенциальные улучшения, но скрывающий код будет сохраняться в будущем еще долгое время после того, как его цель будет отвергнута.
Оптимизация во время разработки кода с использованием макросов принимает разные формы на разных языках.
В некоторых процедурных языках, таких как C и C ++, макросы реализуются с использованием подстановки токена. В настоящее время встроенные функции во многих случаях могут использоваться как безопасная альтернатива. В обоих случаях встроенное тело функции может затем подвергнуться дальнейшей оптимизации компилятора во время компиляции, включая сворачивание констант, что может переместить некоторые вычисления во время компиляции.
Во многих языках функционального программирования макросы реализуются с использованием замены синтаксических деревьев / абстрактных синтаксических деревьев во время синтаксического анализа, что, как утверждается, делает их более безопасными в использовании. Поскольку во многих случаях используется интерпретация, это один из способов гарантировать, что такие вычисления выполняются только во время синтаксического анализа, а иногда и единственный способ.
Lisp создал этот стиль макросов, и такие макросы часто называют «Lisp-подобными макросами». Аналогичного эффекта можно добиться, используя метапрограммирование шаблона в C ++.
. В обоих случаях работа переносится во время компиляции. Разница между макросами C, с одной стороны, и макросами, подобными Lisp, и метапрограммированием шаблонов C++ , с другой стороны, заключается в том, что последние инструменты позволяют выполнять произвольные вычисления. во время компиляции / синтаксического анализа, в то время как раскрытие макросов C не выполняет никаких вычислений и полагается на способность оптимизатора выполнять их. Кроме того, макросы C напрямую не поддерживают рекурсию или итерацию, поэтому не являются полным по Тьюрингу.
, однако, как и любая оптимизация, Часто до завершения проекта сложно предсказать, где такие инструменты окажут наибольшее влияние.
См. Также Категория: Оптимизация компилятора
Оптимизация может быть автоматизирована компиляторами или выполнена программистами. Прибыль обычно ограничена для локальной оптимизации и больше для глобальной оптимизации. Обычно наиболее действенной оптимизацией является поиск более совершенного алгоритма .
Оптимизация всей системы обычно выполняется программистами, поскольку это слишком сложно для автоматических оптимизаторов. В этой ситуации программисты или системные администраторы явно изменяют код, чтобы система в целом работала лучше. Хотя он может повысить эффективность, он намного дороже, чем автоматическая оптимизация. Поскольку многие параметры влияют на производительность программы, пространство для оптимизации программы велико. Метаэвристика и машинное обучение используются для решения сложных задач оптимизации программы.
Используйте профилировщик (или анализатор производительности ), чтобы найти разделы программы, которые забирают больше всего ресурсов - узкое место. Программисты иногда считают, что они имеют четкое представление о том, где находится узкое место, но интуиция часто ошибается. Оптимизация несущественного фрагмента кода обычно мало способствует общей производительности.
Когда узкое место локализовано, оптимизация обычно начинается с переосмысления алгоритма, используемого в программе. Чаще всего конкретный алгоритм может быть специально адаптирован к конкретной проблеме, обеспечивая лучшую производительность, чем общий алгоритм. Например, задача сортировки огромного списка элементов обычно выполняется с помощью процедуры quicksort, которая является одним из наиболее эффективных общих алгоритмов. Но если некоторые характеристики элементов можно использовать (например, они уже расположены в определенном порядке), можно использовать другой метод или даже специальную процедуру сортировки.
После того, как программист убедится, что выбран лучший алгоритм, можно начинать оптимизацию кода. Циклы могут быть развернуты (для снижения накладных расходов цикла, хотя это часто может привести к снижению скорости, если он перегружает кеш ЦП ), можно использовать как можно меньшие типы данных, вместо плавающей можно использовать целочисленную арифметику -точка и так далее. (См. Статью алгоритмическая эффективность для получения информации об этих и других методах.)
Узкие места в производительности могут быть связаны с языковыми ограничениями, а не с алгоритмами или структурами данных, используемыми в программе. Иногда критическая часть программы может быть переписана на другом языке программирования, что дает более прямой доступ к базовой машине. Например, для очень высокоуровневых языков, таких как Python, часто используются модули, написанные на C для большей скорости. Программы, уже написанные на C, могут иметь модули, написанные на сборке. Программы, написанные на D, могут использовать встроенный ассемблер.
Перезапись разделов «окупается» в этих обстоятельствах из-за общего «практического правила », известного как Закон 90/10, который гласит, что 90% времени тратится на 10% кода и только 10% времени на оставшиеся 90% кода. Таким образом, интеллектуальные усилия по оптимизации лишь небольшой части программы могут иметь огромное влияние на общую скорость - если удастся найти правильную часть (части).
Ручная оптимизация иногда имеет побочный эффект в виде снижения читабельности. Таким образом, оптимизации кода должны быть тщательно задокументированы (желательно с использованием встроенных комментариев) и оценены их влияние на будущее развитие.
Программа, выполняющая автоматическую оптимизацию, называется оптимизатором . Большинство оптимизаторов встроены в компиляторы и работают во время компиляции. Оптимизаторы часто могут адаптировать сгенерированный код для конкретных процессоров.
Сегодня автоматизированная оптимизация почти полностью ограничивается оптимизацией компилятора. Однако, поскольку оптимизация компилятора обычно ограничивается фиксированным набором довольно общих оптимизаций, существует значительный спрос на оптимизаторы, которые могут принимать описания проблем и оптимизаций для конкретных языков, что позволяет инженеру определять индивидуальные оптимизации. Инструменты, которые принимают описания оптимизаций, называются системами преобразования программ и начинают применяться к реальным программным системам, таким как C ++.
Некоторые языки высокого уровня (Eiffel, Esterel ) оптимизируют свои программы, используя промежуточный язык.
Grid computing или распределенные вычисления направлены на оптимизацию всей системы путем переноса задач с компьютеров с высокой нагрузкой на компьютеры с простоями.
Иногда время, затраченное на оптимизацию, само по себе может быть проблемой.
Оптимизация существующего кода обычно не добавляет новых функций, и, что еще хуже, она может добавить новые ошибки в ранее работавший код (как и любое изменение). Поскольку код, оптимизированный вручную, иногда может иметь меньшую «читаемость», чем неоптимизированный код, оптимизация также может повлиять на его ремонтопригодность. За оптимизацию приходится платить, и важно быть уверенным, что вложения окупаются.
Автоматический оптимизатор (или оптимизирующий компилятор, программа, которая выполняет оптимизацию кода), возможно, придется оптимизировать сам, либо для дальнейшего повышения эффективности его целевых программ, либо для ускорения собственных операция. Компиляция, выполняемая с "включенной" оптимизацией, обычно занимает больше времени, хотя обычно это проблема только в случае довольно больших программ.
В частности, для оперативных компиляторов производительность компонента компиляции времени выполнения, выполняемого вместе с его целевым кодом, является ключом к общему улучшению скорость исполнения.
 | В Wikibooks есть книга по теме: Оптимизация кода для скорости |
