the bullet points are the arguments why inline is better than a #define macro |
No. Most of the bullet points itemize why an inline function is better than a function call that is not inlined. Each of the bullet points lists an overhead of an explicit function call.
- An inline function does not make an explicit function call, so the there is no overhead of pushing the stack frame nor of a jump instruction to the function.
- Preservation of caller's stack frame. This has no bearing on performance. The caller's stack frame remains intact whether the function is inlined or not. An linlined function "may" push additional variables on the stack.
- New stack frame setup - This doesn't happen with an inlined function.
- Return value - An inlined function "may" return a value. The value is left on the stack just the same as if returned from a non-inlined function.
- Old stack restore - If an inlined function has local storage, these values still have to be poped from the stack, although if the inlined function is small enough, these values will generally be in registers.
- Return. No need for an inlined function to return.
As previously pointed out, inline is merely a suggestion to the compiler and is up to the implementation as to how to implement. YMMV.
As for comparing
inline
to
#define
, IMO, with an optimizing compiler, there might not be any difference. Of course this depends on how well each is written.