3
$\begingroup$

Function inlining is when the function called is directly substituted in the calling code. This avoids the overhead of setting up the call stack, managing any relevant pointers that need to be tracked (instruction pointers, stack pointer, etc.), and seems to be generally faster than actually calling a function.

So, why isn't this done automatically for all functions, given the seemingly many benefits. The compiler may even ignore the inline keyword in C/C++. Are there any general or specific disadvantages to always inlining functions?

$\endgroup$
3
  • 2
    $\begingroup$ binary size, I'm not sure how to write a full answer though $\endgroup$
    – RubenVerg
    Jun 20, 2023 at 5:42
  • $\begingroup$ I feel I should point out that ignoring inline goes both ways - within a translation unit, the compiler may freely inline any invocation based on its own judgement $\endgroup$
    – abel1502
    Jun 20, 2023 at 20:42
  • 1
    $\begingroup$ some compilers do this thing exactly - e.g., OpenCL compilers for some platforms that don't even support function calls. The price for this is that recursion is not allowed, and binary size can explode rather quickly. $\endgroup$
    – SK-logic
    Jun 22, 2023 at 15:46

2 Answers 2

10
$\begingroup$

First, you can't inline all functions: it's quite obviously impossible for recursive functions, first-class functions (closures and those that get passed by a pointer to the function) and "exported" functions that are supposed to be called from elsewhere (dynamically loaded in particular).

Second, as another answer already mentioned, huge functions (written by hand, generated by scripts or resulting from inlining, doesn't matter) increase pressure on the processor's instruction cache, and demand for more registers. The more intermediate values "in flight" we have, the harder put them all in registers, the more we spill on the stack, which slows execution down (also it shows that we can't get rid of a stack pointer even when inlining everything).

On modern processors with speculative execution a function call costs very little, so most of the time inlining isn't that profitable. But in certain cases (in tight loops) inlining is crucial for good performance. Thus the trick is to correctly guess these relatively scarce cases where inlining is a must.

$\endgroup$
7
$\begingroup$

Function inlining isn't always a win. It increases code size, which increases compilation times and may decreased performance due to more pressure in the intruction cache. For some functions the performance benefit might be negligible, but the costs will be the same. There is also the possibility that inlining a function makes it outright slower. For example, if we inline too much the body of the parent function might get too big and difficult to optimize.

$\endgroup$
0

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .