Что плохого в использовании встроенных функций?

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

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

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

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

Я думаю, что обычно нормально, если функция имеет только 1 или 2 оператора.

Изменить: вот что об этом говорится в CodingStyle документе linux :

Глава 15: Внутренняя болезнь

Похоже, существует распространенное заблуждение, что в gcc есть волшебная опция ускорения «сделай меня быстрее», называемая «встроенной». Хотя использование встроенных строк может быть уместным (например, как средство замены макросов, см. Главу 12), очень часто это не так. Обильное использование ключевого слова inline приводит к гораздо большему размеру ядра, что, в свою очередь, замедляет работу системы в целом из-за большего объема памяти icache для ЦП и просто потому, что для кэша страниц доступно меньше памяти. Просто подумай об этом; промах кэша страниц вызывает поиск по диску, который легко занимает 5 миллисекунд. Существует МНОГО циклов процессора, которые могут занимать эти 5 миллисекунд.

Разумное практическое правило - не вставлять встроенные функции в функции, содержащие более трех строк кода. Исключением из этого правила являются случаи, когда известно, что параметр является константой времени компиляции, и в результате этой постоянства вы знаете, что компилятор сможет оптимизировать большую часть вашей функции во время компиляции. . Хороший пример этого более позднего случая можно найти во встроенной функции kmalloc ().

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

Я согласен с другими сообщениями:

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

Третий момент - это может вынудить вас раскрыть детали реализации в ваших заголовках, например,

class OtherObject;

class Object {
public:
    void someFunc(OtherObject& otherObj) {
        otherObj.doIt(); // Yikes requires OtherObj declaration!
    }
};

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

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

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

• В VC ++ используйте ключевое слово __forceinline
• В GCC используйте __attribute __ ((always_inline))

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

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

Я сомневаюсь. Даже компилятор автоматически встраивает некоторые функции для оптимизации.

Я не знаю, связан ли мой ответ с вопросом, но:

Будьте очень осторожны со встроенными виртуальными методами! Некоторые компиляторы с ошибками (например, предыдущие версии Visual C ++) будут генерировать встроенный код для виртуальных методов, где стандартное поведение заключалось в том, чтобы ничего не делать, а идти вниз по дереву наследования и вызывать соответствующий метод.

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

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

с компилятором VC ++ вы можете отменить это решение, используя __forceinline

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

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

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

(Упрощенно) Пример:

Представьте себе простую программу, которая просто вызывает функцию «X» 5 раз.

Если X мало и все вызовы встроены: потенциально все инструкции будут предварительно загружены в кэш инструкций с одним доступом к основной памяти - отлично!

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

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

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

• создавать нестабильность

  • Changing the source of an inline function causes all the users of the header to recompile
  • #includes просачивается в клиента. Это может быть очень неприятно, если вы переработаете встроенную функцию и удалите больше не используемый заголовок, на который полагался какой-то клиент.

• размер исполняемого файла

  • Every time an inline is inlined instead of a call instruction the compiler has to generate the whole code of the inline. This is OK if the code of the function is short (one or two lines), not so good if the function is long
  • Некоторые функции могут производить намного больше кода, чем кажется на первый взгляд. В данном случае речь идет о «тривиальном» деструкторе класса, который имеет множество переменных-членов, не относящихся к поду (или две или 3 переменных-члена с довольно беспорядочными деструкторами). Вызов должен быть сгенерирован для каждого деструктора.

• время исполнения

  • this is very dependent on your CPU cache and shared libraries, but locality of reference is important. If the code you might be inlining happens to be held in cpu cache in one place, a number of clients can find the code an not suffer from a cache miss and the subsequent memory fetch (and worse, should it happen, a disk fetch). Sadly this is one of those cases where you really need to do performance analysis.

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

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

2. есть несколько других ситуаций, когда встроенный может не работать

   1. does not work in case of recursive function.
   2. Он также может не работать со статической переменной.
   3. он также не работает в случае использования цикла, переключателя и т. д. или мы можем сказать, что с несколькими операторами.
   4. И функция main не может работать как встроенная функция.