<p><a href="https://en.wikipedia.org/wiki/Inline_function" rel="nofollow noreferrer">Function inlining</a> 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.</p>
<p>So, why isn't this done automatically for all functions, given the seemingly many benefits. The compiler may even ignore the <code>inline</code> keyword in C/C++. Are there any general or specific disadvantages to always inlining functions?</p>

<functions><optimization><inlining>
What are the disadvantages of automatically inlining all functions?
CC BY-SA 4.0
2023-06-20T05:42:00.580Z
binary size, I'm not sure how to write a full answer though
RubenVerg
CC BY-SA 4.0
2023-06-20T20:42:39.750Z
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
abel1502
CC BY-SA 4.0
2023-06-22T15:46:41.793Z
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.
SK-logic
<p>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.</p>

CC BY-SA 4.0
2023-06-20T06:10:54.537Z
2023-06-20T06:10:54.537Z
hugomg
<p>First, you can't inline <em>all</em> 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 &quot;exported&quot; functions that are supposed to be called from elsewhere (dynamically loaded in particular).</p>
<p>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 &quot;in flight&quot; 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).</p>
<p>On modern processors with speculative execution a function call costs <em>very</em> little, so <em>most</em> of the time inlining isn't that profitable. But in certain cases (in tight loops) inlining is <em>crucial</em> for good performance. Thus the trick is to correctly guess these relatively scarce cases where inlining is a must.</p>

CC BY-SA 4.0
2023-06-20T06:57:10.150Z
2023-06-20T06:57:10.150Z
Alex Chichigin
# What are the disadvantages of automatically inlining all functions?
Posted by: username_0 on 2023-06-20
[Function inlining](https://en.wikipedia.org/wiki/Inline_function) 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?
**Tags:** functions optimization inlining
> **Comments:**
> **username_1**: binary size, I'm not sure how to write a full answer though  
> **username_2**: 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  
> **username_3**: 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.  
---
## 2 answers
### Answer by username_5 on 2023-06-20. Score: 10
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.
---
### Answer by username_4 on 2023-06-20. Score: 7
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.
---
