Inline Expansion - Problems

Problems

Replacing a call site with an expanded function body can worsen performance in several ways :

• In applications where code size is more important than speed, such as many embedded systems, inlining is usually disadvantageous except for very small functions, such as trivial mutator methods.
• The increase in code size may cause a small, critical section of code to no longer fit in the cache, causing cache misses and slowdown.
• The added variables from the inlined procedure may consume additional registers, and in an area where register pressure is already high this may force spilling, which causes additional RAM accesses.
• A language specification may allow a program to make additional assumptions about arguments to procedures that it can no longer make after the procedure is inlined.
• If code size is increased too much, resource constraints such as RAM size may be exceeded, leading to programs that either cannot be run or that cause thrashing. Today, this is unlikely to be an issue with desktop or server computers except with very aggressive inlining, but it can still be an issue for embedded systems.

Typically, compiler developers keep these issues in mind, and incorporate heuristics into their compilers that choose which functions to inline so as to improve performance, rather than worsening it, in most cases.