Question

Inline functions are just a request to compilers that insert the complete body of the inline function in every place in the code where that function is used.

But how the compiler decides whether it should insert it or not? Which algorithm/mechanism it uses to decide?

Thanks,

Naveen

Answer 1

Some common aspects:

• Compiler option (debug builds usually don’t inline, and most compilers have options to override the inline declaration to try to inline all, or none)
• suitable calling convention (e.g. varargs functions usually aren’t inlined)
• suitable for inlining: depends on size of the function, call frequency of the function, gains through inlining, and optimization settings (speed vs. code size). Often, tiny functions have the most benefits, but a huge function may be inlined if it is called just once
• inline call depth and recursion settings

The 3rd is probably the core of your question, but that’s really “compiler specific heuristics” – you need to check the compiler docs, but usually they won’t give much guarantees. MSDN has some (limited) information for MSVC.

Beyond trivialities (e.g. simple getters and very primitive functions), inlining as such isn’t very helpful anymore. The cost of the call instruction has gone down, and branch prediction has greatly improved.

The great opportunity for inlining is removing code paths that the compiler knows won’t be taken – as an extreme example:

inline int Foo(bool refresh = false)
{
   if (refresh)
   {
      // ...extensive code to update m_foo  
   }
   return m_foo;
}

A good compiler would inline Foo(false), but not Foo(true).

With Link Time Code Generation, Foo could reside in a .cpp (without a inline declararion), and Foo(false) would still be inlined, so again inline has only marginal effects here.

---

To summarize: There are few scenarios where you should attempt to take manual control of inlining by placing (or omitting) inline statements.