Когда использовать встроенную функцию, а когда нет?

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

Итак, на каком основании можно определить, является ли функция кандидатом на встраивание или нет? В каком случае следует избегать встраивания?

Избежать затрат на вызов функции - это только половина дела.

делать:

• использовать inlineвместо#define
• очень маленькие функции являются хорошими кандидатами для inline: более быстрого кода и меньших исполняемых файлов (больше шансов остаться в кеше кода)
• функция маленькая и вызывается очень часто

нет:

• большие функции: приводит к большим исполняемым файлам, что значительно снижает производительность независимо от более быстрого выполнения, которое возникает в результате накладных расходов на вызовы
• встроенные функции, связанные с вводом / выводом
• функция используется редко
• конструкторы и деструкторы: даже если они пусты, компилятор генерирует для них код
• нарушение бинарной совместимости при разработке библиотек:
  • встроить существующую функцию
  • изменить встроенную функцию или сделать встроенную функцию не встроенной: предыдущая версия библиотеки вызывает старую реализацию

при разработке библиотеки, чтобы сделать класс расширяемым в будущем, вы должны:

• добавить не встроенный виртуальный деструктор, даже если тело пусто
• сделать все конструкторы не встроенными
• писать не встроенные реализации конструктора копирования и оператора присваивания, если класс не может быть скопирован по значению

Помните, что inlineключевое слово является подсказкой для компилятора: компилятор может решить не встроить функцию, и он может решить встроить функции, которые не были отмечены inlineв первую очередь. Я вообще избегаю маркировки inline(возможно, когда пишу очень маленькие функции).

Что касается производительности, мудрый подход (как всегда) заключается в профилировании приложения, а затем в конечном итоге inlineнабора функций, представляющих узкое место.

Ссылки:

• Встраивать или не встраивать
• [9] Встроенные функции
• Политики / Проблемы двоичной совместимости с C ++
• ПОЛУЧИЛ № 33: Встроенный
• Встроенный Redux
• Эффективный C ++ - Пункт 33: Используйте встраивание разумно

РЕДАКТИРОВАТЬ: Бьярне Страуструп, Язык программирования C ++:

Функция может быть определена как inline. Например:

inline int fac(int n)
{
  return (n < 2) ? 1 : n * fac(n-1);
}

Спецификатор inlineявляется подсказкой для компилятора, что он должен попытаться сгенерировать код для вызова fac()inline, а не записывать код для функции один раз, а затем вызывать через обычный механизм вызова функции. Умный компилятор может сгенерировать константу 720для вызова fac(6). Возможность взаимно рекурсивных встроенных функций, встроенных функций, которые повторяются или не зависят от ввода и т. Д., Делает невозможным гарантирование того, что каждый вызов inlineфункции действительно встроен. Степень хитрости компилятора не может быть законодательно установлена, поэтому один компилятор может генерировать 720, другой 6 * fac(5)и еще один необъявленный вызов fac(6).

Чтобы сделать встраивание возможным в отсутствие необычайно умных средств компиляции и компоновки, в область действия должно входить определение, а не просто объявление встроенной функции (§9.2). inlineEspecifier не влияет на семантику функции. В частности, встроенная функция по-прежнему имеет уникальный адрес и staticпеременные (§7.1.2) встроенной функции.

EDIT2: ISO-IEC 14882-1998, 7.1.2 Спецификаторы функций

Объявление функции (8.3.5, 9.3, 11.4) со inlineспецификатором объявляет встроенную функцию. Встроенный спецификатор указывает реализации, что внутренняя замена тела функции в точке вызова должна быть предпочтительнее обычного механизма вызова функции. Реализация не требуется для выполнения этой внутренней замены в точке вызова; однако, даже если эта встроенная замена не указана, другие правила для встроенных функций, определенные в 7.1.2, все равно должны соблюдаться.

inlineимеет очень мало общего с оптимизацией. inlineявляется инструкцией для компилятора не выдавать ошибку, если заданное определение функции встречается в программе несколько раз, и обещание, что определение будет появляться в каждом используемом им переводе и везде, где оно появляется, будет иметь точно такое же определение.

Учитывая вышеприведенные правила, inlineподходит для коротких функций, в теле которых нет необходимости включать дополнительные зависимости от того, что понадобится только для объявления. Каждый раз, когда определение встречается, оно должно быть проанализировано, и может быть сгенерирован код для его тела, так что это подразумевает некоторые накладные расходы компилятора на функцию, определенную только один раз в одном исходном файле.

Компилятор может встроить (т.е. заменить вызов функции кодом, выполняющим это действие этой функции) любой вызов функции, который он выберет. Раньше было так, что «очевидно» не могло встроить функцию, которая не была объявлена ​​в том же модуле трансляции, что и вызов, но с растущим использованием оптимизации времени соединения, даже сейчас это не так. В равной степени верно и то, что отмеченные функции inlineне могут быть встроенными.

Указание компилятору встроить функцию - это оптимизация, и самое важное правило оптимизации заключается в том, что преждевременная оптимизация является корнем всего зла. Всегда пишите чистый код (используя эффективные алгоритмы), затем профилируйте свою программу и оптимизируйте только те функции, которые занимают слишком много времени.

Если вы обнаружите, что конкретная функция очень коротка и проста, и она вызывается десятки тысяч раз в тесном внутреннем цикле, это может быть хорошим кандидатом.

Однако вы можете быть удивлены - многие компиляторы C ++ автоматически встроат для вас небольшие функции - и они могут также игнорировать ваш запрос на встроенные функции.

Лучший способ выяснить это - профилировать вашу программу и пометить небольшие функции, которые вызываются много раз и прожигать циклы ЦП inline. Ключевое слово здесь - «маленький» - как только издержки вызова функции незначительны по сравнению с временем, потраченным на функцию, бессмысленно их включать.

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

Преждевременная оптимизация - корень всего зла!

Как правило, я обычно включаю только «получатели» и «установщики». Как только код заработает и станет стабильным, профилирование может показать, какие функции могут извлечь выгоду из встраивания.

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

Повторное использование - напишите встроенные однострочные функции, а потом позаботьтесь о других.

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

Вы можете прочитать больше о inline в faq c ++

Я часто использую встроенные функции не для оптимизации, а для того, чтобы сделать код более читабельным. Иногда сам код короче и его легче понять, чем комментарии, описательные имена и т. Д. Например:

void IncreaseCount() { freeInstancesCnt++; }

Читатель сразу знает полную семантику кода.

Я обычно следую правилу большого пальца, где я делаю функцию с 3-4 простыми утверждениями как встроенными. Но хорошо помнить, что это всего лишь подсказка компилятору. Последний вызов, чтобы сделать его встроенным или нет, принимается только компилятором. Если их будет больше, чем много, я не буду объявлять их как встроенные, так как с тупым компилятором это может привести к раздуванию кода.

Лучшим способом было бы изучить и сравнить сгенерированные инструкции для встроенных и не встроенных. Тем не менее, это всегда безопасно опустить inline. Использование inlineможет привести к неприятностям, которые вам не нужны.

Принимая решение о том, использовать ли inline, я обычно имею в виду следующую идею: на современных машинах задержка памяти может быть более узким местом, чем необработанные вычисления. Известно, что часто вызываемые встроенные функции увеличивают размер исполняемого файла. Кроме того, такая функция может быть сохранена в кеше кода ЦП, что уменьшит количество пропусков кеша, когда к этому коду необходимо получить доступ.

Следовательно, вы должны решить для себя: увеличивает или уменьшает встроенный размер генерируемого машинного кода? Насколько вероятно, что вызов функции приведет к отсутствию кэша? Если это будет распространено по всему коду, то я бы сказал, что вероятность высока. Если он ограничен одним узким контуром, то вероятность, надеюсь, низкая.

Я обычно использую встраивание в случаях, перечисленных ниже. Однако, если вы действительно обеспокоены производительностью, профилирование необходимо. Кроме того, вы можете проверить, действительно ли компилятор принимает подсказку.

• Короткие процедуры, которые вызываются в узком цикле.
• Очень простые средства доступа (получить / установить) и функции-оболочки.
• Код шаблона в заголовочных файлах, к сожалению, автоматически получает встроенную подсказку.
• Короткий код, который используется как макрос. (Например, мин () / макс ())
• Короткие математические упражнения.

Кроме того, встроенный метод имеет серьезные побочные эффекты при ведении больших проектов. При изменении встроенного кода все файлы, которые его используют, будут автоматически перекомпилированы компилятором (если это хороший компилятор). Это может потратить много времени на разработку.

Когда inlineметод переносится в исходный файл и больше не указывается, весь проект должен быть перестроен (по крайней мере, это был мой опыт). А также когда методы конвертируются во встроенные.

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

Когда вы думаете, что ваш код достаточно мал для использования в качестве встроенного, и помните, что встроенная функция дублирует ваш код и вставляет его при вызове функции, поэтому она может быть достаточно хороша для увеличения времени выполнения, но также и для увеличения потребления памяти. Вы не можете использовать встроенную функцию, когда используете циклическую / статическую переменную / рекурсивную / switch / goto / виртуальную функцию. Виртуальные средства ждут до времени выполнения, а встроенные - во время компиляции, поэтому их нельзя использовать одновременно.

Я прочитал некоторые ответы и вижу, что некоторые вещи отсутствуют.

Правило, которое я использую, не должно использовать inline, если я не хочу, чтобы оно было встроенным. Выглядит глупо, теперь объяснение.

Компиляторы достаточно умны, а короткие функции всегда делают встроенными. И никогда не заставляет long работать как inline, если только программист не сказал, что это нужно.

Я знаю что inline это подсказка или запрос к компилятору

На самом деле inlineэто заказ для компилятора, у него нет выбора, и после inlineключевого слова весь код встроен. Таким образом, вы никогда не сможете использовать inlineключевое слово, и компилятор разработает самый короткий код.

Так когда же использовать inline?

Использовать, если вы хотите иметь встроенный код. Я знаю только один пример, потому что я использую его только в одной ситуации. Это аутентификация пользователя.

Например, у меня есть эта функция:

inline bool ValidUser(const std::string& username, const std::string& password)
{
    //here it is quite long function
}

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