I know that inline is a hint or request to compiler and its used to avoid function call overheads.
So on what basis one can determine whether a function is a candidate for inlining or not ? In which case one should avoid inlining ?
I know that inline is a hint or request to compiler and its used to avoid function call overheads.
So on what basis one can determine whether a function is a candidate for inlining or not ? In which case one should avoid inlining ?
I often use inline functions not as an optimization but to make the code more readable. Sometimes the code itself is shorter and easier to understand than comments, descriptive names etc. For example:
The reader immediately knows the complete semantics of the code.
Avoiding the cost of a function call is only half the story.
do:
inline
instead of#define
inline
: faster code and smaller executables (more chances to stay in the code cache)don't:
when developing a library, in order to make a class extensible in the future you should:
Remember that the
inline
keyword is a hint to the compiler: the compiler may decide not to inline a function and it can decide to inline functions that were not markedinline
in the first place. I generally avoid marking functioninline
(apart maybe when writing very very small functions).About performance, the wise approach is (as always) to profile the application, then eventually
inline
a set of functions representing a bottleneck.References:
EDIT: Bjarne Stroustrup, The C++ Programming Language:
EDIT2: ISO-IEC 14882-1998, 7.1.2 Function specifiers
inline
has very little to do with optimization.inline
is an instruction to the compiler not to produce an error if the function given definition occurs multiple times in the program and a promise that the definition will occur in every translation that it is used and everywhere it does appear it will have exactly the same definition.Given the above rules,
inline
is suitable for short functions whose body doesn't necessitate including extra dependencies over what just a declaration would need. Every time the defintion is encountered it must be parsed and code for its body may be generated so it implies some compiler overhead over a function defined only once in a single source file.A compiler may inline (i.e. replace a call to the function with code that performs that action of that function) any function call that it chooses. It used to be the case that it "obviously" couldn't inline a function that wasn't declared in the same translation unit as the call but with the increasing use of link time optimization even this isn't true now. Equally true is the fact that functions marked
inline
may not be inlined.Telling the compiler to inline a function is an optimization, and the most important rule of optimization is that premature optimization is the root of all evil. Always write clear code (using efficient algorithms), then profile your program and only optimize functions that are taking too long.
If you find a particular function is very short and simple, and it's getting called tens of thousands of times in a tight inner loop, it might be a good candidate.
You might be surprised, though - many C++ compilers will automatically inline small functions for you - and they might ignore your request to inline, too.
Premature optimization is the root of all evil!
As a rule of thumb I usually inline only "getters" and "setters". Once the code is working and is stable, profiling can show which functions could benefit from inlining.
On the other hand, most modern compilers have quite good optimization algorithms, and will inline what you should have inlined for you.
Reasuming -- write inline one-liner functions, and worry about others later.
One should use the inline function qualifier only when the function code is small.If the functions are larger you should prefer the normal functions since the saving in memory space is worth the comparatively small sacrifice in execution speed.