Related
I know that inline is a hint or request to the compiler and is 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?
Avoiding the cost of a function call is only half the story.
do:
use inline instead of #define
very small functions are good candidates for inline: faster code and smaller executables (more chances to stay in the code cache)
the function is small and called very often
don't:
large functions: leads to larger executables, which significantly impairs performance regardless of the faster execution that results from the calling overhead
inline functions that are I/O bound
the function is seldom used
constructors and destructors: even when empty, the compiler generates code for them
breaking binary compatibility when developing libraries:
inline an existing function
change an inline function or make an inline function non-inline: prior version of the library call the old implementation
when developing a library, in order to make a class extensible in the future you should:
add non-inline virtual destructor even if the body is empty
make all constructors non-inline
write non-inline implementations of the copy constructor and assignment operator unless the class cannot be copied by value
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 marked inline in the first place. I generally avoid marking function inline (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:
To Inline or Not To Inline
[9] Inline functions
Policies/Binary Compatibility Issues With C++
GotW #33: Inline
Inline Redux
Effective C++ - Item 33: Use inlining judiciously
EDIT: Bjarne Stroustrup, The C++ Programming Language:
A function can be defined to be inline. For example:
inline int fac(int n)
{
return (n < 2) ? 1 : n * fac(n-1);
}
The inline specifier is a hint to the compiler that it should attempt to generate code for a call of fac() inline rather than laying down the code for the function once and then calling through the usual function call mechanism. A clever compiler can generate the constant 720 for a call fac(6). The possibility of mutually recursive inline functions, inline functions that recurse or not depending on input, etc., makes it impossible to guarantee that every call of an inline function is actually inlined. The degree of cleverness of a compiler cannot be legislated, so one compiler might generate 720, another 6 * fac(5), and yet another an un-inlined call fac(6).
To make inlining possible in the absence of unusually clever compilation and linking facilities, the definition–and not just the declaration–of an inline function must be in scope (§9.2). An inline especifier does not affect the semantics of a function. In particular, an inline function still has a unique address and so has static variables (§7.1.2) of an inline function.
EDIT2: ISO-IEC 14882-1998, 7.1.2 Function specifiers
A function declaration (8.3.5, 9.3, 11.4) with an inline specifier declares an inline function. The inline specifier indicates to the implementation that inline substitution of the function body at the point of call is to be preferred to the usual function call mechanism. An implementation is not required to perform this inline substitution at the point of call; however, even if this inline substitution is omitted, the other rules for inline functions defined by 7.1.2 shall still be respected.
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.
The best way to find out is to profile your program and mark small functions that get called lots of times and burn through CPU cycles that as inline. The keyword here is "small" - once the function call overhead is negligible compared to the time spent in the function, it's pointless to inline them.
The other use I'd suggest is if you've got small functions that get called in performance critical code often enough to make a cache miss relevant, you should probably inline those as well. Again, it's something the profiler should be able to tell you.
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:
void IncreaseCount() { freeInstancesCnt++; }
The reader immediately knows the complete semantics of the code.
The best way would be to examine and compare the generated instructions for inlined and not inlined. However, it is always safe to omit inline. Using inline could lead to trouble you don't want.
Inline functions might improve your code performance by eliminating the need to push arguments into the stack.
if the function in question is in a critical part of your code you should make the inline not inline decision in the optimization part of your project,
you can read more about inlines in the c++ faq
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.
I generally follow a thumb rule where I make a function with 3-4 simple statements as inline. But it is good to remember that it is just a hint to the compiler. The final call to make it inline or not is taken by the compiler only. If there are more than these many statements I will not declare inline as with a stupid compiler it may lead to code bloat.
When deciding on whether to use inline, I usually keep the following idea in mind: On modern machines memory latency can be a bigger bottleneck than raw calculations. Inlining functions that are called often is known to grow the executable size. Furthermore, such a function could be stored in the CPU's code cache which will decrease the number of cache misses when that code needs to be accessed.
Hence, you have to decide for yourself: Does inlining increase or decrease the size of the generated machine code? How likely is it that calling the function will cause a cache miss? If it is peppered throughout the code, then I would say the likelihood is high. If it is restricted to a single tight loop then the likelihood is hopefully low.
I typically use inlining in the cases I list bellow. However, where you are genuinely concerned about performance, profiling is essential. Furthermore, you might want to check whether the compiler actually takes the hint.
Short routines that are called in a tight loop.
Very basic accessors (get / set) and wrapper functions.
Template code in header files unfortunately automatically obtain the inline hint.
Short code that is used like a macro. (E.g. min() / max())
Short math routines.
Also, an inline method has severe side effects when maintaining large projects. When the inline code is changed, all files that use it will be rebuild automatically by the compiler (it it is a good compiler). This could waste a lot of your development time.
When an inline method is transferred to a source file and not inlined any more, the whole project must be rebuilt (at least this has been my experience). And also when methods are converted to inline.
When you think your code is small enough to be used as inline and remember inline function duplicate your code and paste it were the function is called so it may be good enough to increase your execution time but increased memory consumption also.
You can't use inline function when you are using a loop/static variable/recursive/switch/goto/Virtual function.
Virtual means wait until runtime and inline means during compilation so they can't be use simultaneously.
I have read some answers and see that there some stuff missing.
The rule I use is not to use inline, unless I want it to be inline. Looks silly, now explanation.
Compilers are smart enough and short functions always makes inline. And never makes long function as inline, unless programmer said to do that.
I know that inline is a hint or request to compiler
Actually inline is an order for compiler, it has no choices and after inline keyword makes all code inline. So you can never use inline keyword and compiler will design shortest code.
So when to use inline?
To use if you want to have some code inline. I know only one example, because I use it in only one situation. It is user authentication.
For example I have this function:
inline bool ValidUser(const std::string& username, const std::string& password)
{
//here it is quite long function
}
No matter how big this function is I want to have it as inline because it makes my software harder to crack.
What is the advantages/disadvantages of using inline functions in C++? I see that it only increases performance for the code that the compiler outputs, but with today's optimized compilers, fast CPUs, huge memory etc. (not like in the 1980< where memory was scarce and everything had to fit in 100KB of memory) what advantages do they really have today?
Advantages
By inlining your code where it is needed, your program will spend less time in the function call and return parts. It is supposed to make your code go faster, even as it goes larger (see below). Inlining trivial accessors could be an example of effective inlining.
By marking it as inline, you can put a function definition in a header file (i.e. it can be included in multiple compilation unit, without the linker complaining)
Disadvantages
It can make your code larger (i.e. if you use inline for non-trivial functions). As such, it could provoke paging and defeat optimizations from the compiler.
It slightly breaks your encapsulation because it exposes the internal of your object processing (but then, every "private" member would, too). This means you must not use inlining in a PImpl pattern.
It slightly breaks your encapsulation 2: C++ inlining is resolved at compile time. Which means that should you change the code of the inlined function, you would need to recompile all the code using it to be sure it will be updated (for the same reason, I avoid default values for function parameters)
When used in a header, it makes your header file larger, and thus, will dilute interesting informations (like the list of a class methods) with code the user don't care about (this is the reason that I declare inlined functions inside a class, but will define it in an header after the class body, and never inside the class body).
Inlining Magic
The compiler may or may not inline the functions you marked as inline; it may also decide to inline functions not marked as inline at compilation or linking time.
Inline works like a copy/paste controlled by the compiler, which is quite different from a pre-processor macro: The macro will be forcibly inlined, will pollute all the namespaces and code, won't be easily debuggable, and will be done even if the compiler would have ruled it as inefficient.
Every method of a class defined inside the body of the class itself is considered as "inlined" (even if the compiler can still decide to not inline it
Virtual methods are not supposed to be inlinable. Still, sometimes, when the compiler can know for sure the type of the object (i.e. the object was declared and constructed inside the same function body), even a virtual function will be inlined because the compiler knows exactly the type of the object.
Template methods/functions are not always inlined (their presence in an header will not make them automatically inline).
The next step after "inline" is template metaprograming . I.e. By "inlining" your code at compile time, sometimes, the compiler can deduce the final result of a function... So a complex algorithm can sometimes be reduced to a kind of return 42 ; statement. This is for me extreme inlining. It happens rarely in real life, it makes compilation time longer, will not bloat your code, and will make your code faster. But like the grail, don't try to apply it everywhere because most processing cannot be resolved this way... Still, this is cool anyway...:-p
Inline functions are faster because you don't need to push and pop things on/off the stack like parameters and the return address; however, it does make your binary slightly larger.
Does it make a significant difference? Not noticeably enough on modern hardware for most. But it can make a difference, which is enough for some people.
Marking something inline does not give you a guarantee that it will be inline. It's just a suggestion to the compiler. Sometimes it's not possible such as when you have a virtual function, or when there is recursion involved. And sometimes the compiler just chooses not to use it.
I could see a situation like this making a detectable difference:
inline int aplusb_pow2(int a, int b) {
return (a + b)*(a + b) ;
}
for(int a = 0; a < 900000; ++a)
for(int b = 0; b < 900000; ++b)
aplusb_pow2(a, b);
In archaic C and C++, inline is like register: a suggestion (nothing more than a suggestion) to the compiler about a possible optimization.
In modern C++, inline tells the linker that, if multiple definitions (not declarations) are found in different translation units, they are all the same, and the linker can freely keep one and discard all the other ones.
inline is mandatory if a function (no matter how complex or "linear") is defined in a header file, to allow multiple sources to include it without getting a "multiple definition" error by the linker.
Member functions defined inside a class are "inline" by default, as are template functions (in contrast to global functions).
//fileA.h
inline void afunc()
{ std::cout << "this is afunc" << std::endl; }
//file1.cpp
#include "fileA.h"
void acall()
{ afunc(); }
//main.cpp
#include "fileA.h"
void acall();
int main()
{
afunc();
acall();
}
//output
this is afunc
this is afunc
Note the inclusion of fileA.h into two .cpp files, resulting in two instances of afunc().
The linker will discard one of them.
If no inline is specified, the linker will complain.
Inlining is a suggestion to the compiler which it is free to ignore. It's ideal for small bits of code.
If your function is inlined, it's basically inserted in the code where the function call is made to it, rather than actually calling a separate function. This can assist with speed as you don't have to do the actual call.
It also assists CPUs with pipelining as they don't have to reload the pipeline with new instructions caused by a call.
The only disadvantage is possible increased binary size but, as long as the functions are small, this won't matter too much.
I tend to leave these sorts of decisions to the compilers nowadays (well, the smart ones anyway). The people who wrote them tend to have far more detailed knowledge of the underlying architectures.
Inline function is the optimization technique used by the compilers. One can simply prepend inline keyword to function prototype to make a function inline. Inline function instruct compiler to insert complete body of the function wherever that function got used in code.
Advantages :-
It does not require function calling overhead.
It also save overhead of variables push/pop on the stack, while function calling.
It also save overhead of return call from a function.
It increases locality of reference by utilizing instruction cache.
After in-lining compiler can also apply intra-procedural optimization if specified. This is the most important one, in this way compiler can now focus on dead code elimination, can give more stress on branch prediction, induction variable elimination etc..
To check more about it one can follow this link
http://tajendrasengar.blogspot.com/2010/03/what-is-inline-function-in-cc.html
I'd like to add that inline functions are crucial when you are building shared library. Without marking function inline, it will be exported into the library in the binary form. It will be also present in the symbols table, if exported. On the other side, inlined functions are not exported, neither to the library binaries nor to the symbols table.
It may be critical when library is intended to be loaded at runtime. It may also hit binary-compatible-aware libraries. In such cases don't use inline.
During optimization many compilers will inline functions even if you didn't mark them. You generally only need to mark functions as inline if you know something the compiler doesn't, as it can usually make the correct decision itself.
inline allows you to place a function definition in a header file and #include that header file in multiple source files without violating the one definition rule.
Generally speaking, these days with any modern compiler worrying about inlining anything is pretty much a waste of time. The compiler should actually optimize all of these considerations for you through its own analysis of the code and your specification of the optimization flags passed to the compiler. If you care about speed, tell the compiler to optimize for speed. If you care about space, tell the compiler to optimize for space. As another answer alluded to, a decent compiler will even inline automatically if it really makes sense.
Also, as others have stated, using inline does not guarantee inline of anything. If you want to guarantee it, you will have to define a macro instead of an inline function to do it.
When to inline and/or define a macro to force inclusion? - Only when you have a demonstrated and necessary proven increase in speed for a critical section of code that is known to have an affect on the overall performance of the application.
It is not all about performance. Both C++ and C are used for embedded programming, sitting on top of hardware. If you would, for example, write an interrupt handler, you need to make sure that the code can be executed at once, without additional registers and/or memory pages being being swapped. That is when inline comes in handy. Good compilers do some "inlining" themselves when speed is needed, but "inline" compels them.
Fell into the same trouble with inlining functions into so libraries. It seems that inlined functions are not compiled into the library. as a result the linker puts out a "undefined reference" error, if a executable wants to use the inlined function of the library. (happened to me compiling Qt source with gcc 4.5.
Why not make all functions inline by default? Because it's an engineering trade off. There are at least two types of "optimization": speeding up the program and reducing the size (memory footprint) of the program. Inlining generally speeds things up. It gets rid of the function call overhead, avoiding pushing then pulling parameters from the stack. However, it also makes the memory footprint of the program bigger, because every function call must now be replaced with the full code of the function. To make things even more complicated, remember that the CPU stores frequently used chunks of memory in a cache on the CPU for ultra-rapid access. If you make the program's memory image big enough, your program won't be able to use the cache efficiently, and in the worst case inlining could actually slow your program down. To some extent the compiler can calculate what the trade offs are, and may be able to make better decisions than you can, just looking at the source code.
Our computer science professor urged us to never use inline in a c++ program. When asked why, he kindly explained to us that modern compilers should detect when to use inline automatically.
So yes, the inline can be an optimization technique to be used wherever possible, but apparently this is something that is already done for you whenever it's possible to inline a function anyways.
Conclusion from another discussion here:
Are there any drawbacks with inline functions?
Apparently, There is nothing wrong with using inline functions.
But it is worth noting the following points!
Overuse of inlining can actually make programs slower. Depending on a function's size, inlining it can cause the code size to increase or decrease. Inlining a very small accessor function will usually decrease code size while inlining a very large function can dramatically increase code size. On modern processors smaller code usually runs faster due to better use of the instruction cache. - Google Guidelines
The speed benefits of inline functions tend to diminish as the function grows in size. At some point the overhead of the function call becomes small compared to the execution of the function body, and the benefit is lost - Source
There are few situations where an inline function may not work:
For a function returning values; if a return statement exists.
For a function not returning any values; if a loop, switch or goto statement exists.
If a function is recursive. -Source
The __inline keyword causes a function to be inlined only if you specify the optimize option. If optimize is specified, whether or not __inline is honored depends on the setting of the inline optimizer option. By default, the inline option is in effect whenever the optimizer is run. If you specify optimize , you must also specify the noinline option if you want the __inline keyword to be ignored. -Source
First of all, I would like to state the facts I know about 'inline', so that you don't bother to restate them.
An inline function is a special kind of function whose definition must be available in every translation unit in which the function is used.
It is a hint to the compiler (which it is free to ignore) to omit the function call, and expand the body instead of the call.
The only pro I know of is that (2.) may make the code faster.
The only con I know if is that (1.) increases coupling which is bad.
Now let's consider templates. If I have a template library, I need to provide the definitions of the function templates in every translation unit, right? Let's forget about the controversial 'export' for a while, since it doesn't really solve the problem anyway.
So, I come to a conclusion that there is no reason not to make a template function inline because the only con of inline I know of is there a priori.
Please correct me if I am wrong.
Thanks in advance.
The only pro I know of is that (2.) may make the code faster.
May being the operative word. Inlined functions may make certain code paths faster, yes.
But an inlined function puts additional pressure on the instruction cache on most modern CPUs. If your function is too large to fit in the L1 instruction cache, it may actually run slower than performing a function call (for which the CPU can optimize by prefetching the function and its return site).
Inlining a function may also put undue pressure on the L2 cache - if an inlined function is used an unusually large number of times, the extra code size will increase the likelihood of cache misses, leading to long delays and pipeline stalls as the CPU twiddles its thumbs waiting for the memory bus to do something.
inline is far from being a silver bullet. Compilers with aggressive optimization will ignore the inline hint completely, as they will instead choose functions to inline based on heuristics such as code size or the presence of branches, irrespective of the presence or absence of the inline keyword.
The only con I know if is that (1.) increases coupling which is bad.
This is something I've never heard. "Coupling" is a concept I've only heard used when describing the high-level relationships of code. It's more an issue of maintainability and generality of code. inline is an issue of low-level code generation.
As to templates, again, an aggressively-optimizing compiler will inline if its heuristics show an advantage to doing so.
There is, however, a link-level issue to consider: You may need to declare a function or template inline (or static, depending on the situation) in order to eliminate duplicate symbols at link time or restrict symbol visibility. This is, of course, not an optimization.
In summary, don't bother using the inline keyword except when specifically required.
I think you shouldn't bother with writing inline or not before template function definitions. I think most compilers will inline small functions anyway, whether you ask them or not. Some compilers are even able to do this at link time for functions defined in only one translation unit.
Imho, the only point to the inline keyword is to be able to define non-template functions inside headers, for those compilers who don't inline at link time (or when you want a "header only" library).
you don't need to provide the definition in every translation -- only the unes that use them ;)
it does matter whether you declare them inline or not. the compiler may acknowledge your use of the keyword (or of other force inline declarations). the compiler may generate exported classes/functions from your template definitions. if somebody asked me whether to inline by default or not (knowing they do not know the effect of using it), i would say: "don't use it", because the compiler has a better understanding of your program. optimizations are made differently among compilers.
example:
let's say the compiler inlines some functions at your request
inlining expansion during optimization typically caps out at a certain number of instructions... oops - the compiler just popped the stuff it should have inlined out of line because the body was too large with these templates which are inline by default.
or you may end up with an extra-large binary
so you're tying one hand behind the compiler's back when you inline by default (provided, of course it acknowledges your use of the keyword).
in general: if you don't know, trust the compiler (writers).
there are a few cases where i declare inline by default (even if it just to reduce exported symbols).
other benefits of inlining:
inlining can make code/functions smaller
inlining can reduce the number of exported symbols
it may also allow the compiler to make better optimizations, because it is able to 'see' more of the program during optimization.
By being inline, it removes the overhead of creating and destroying a new stack frame, and jumping to another location in the exe. This makes the code ever so slightly faster.
The down side is, ofcourse, the increase in exe size, because the function must be implemented where-ever it is called.
EDIT
Inlining functions is only worthwhile when it is called many times and the function size is small. Otherwise, the increase in file size may actually make the program slower, and it really isn't worth while.
what are the requirement for a function so it could be executed inline in c++?
is there a case that a function can't be inline?
or any function can be inline and it is the responsibility of the programmer to decide how to define the function, based on run time and compilation-time considerations?
It depends what you mean. If you mean, when can the function be expanded in-line, removing a function call, then that is really up to the compiler. It may inline almost any function, and refuse to inline almost any function that you ask it to. Functions that probably won't be inlined include recursive ones, and ones where you have taken the function's address. On the whole, it's better not to think about this much.
The main use for the inline keyword is not to request inlining, but to indicate that the function may be #included in multiple translation units without causing multiple definition errors.
what are the requirement for a
function so it could be executed
inline in c++?
It needs to be defined at every spot in which it's called (typically this is done by putting it in a .h).
is there a case that a function can't
be inline?
Not in terms of the language standard, I believe, although of course each compiler can and will implement some restrictions of its own.
or any function can be inline and it
is the responsibility of the
programmer to decide how to define the
function, based on run time and
compilation-time considerations?
The inline keyword is just a hint from the programmer to the compiler that the programmer would really like this function to be inlined (presumably the programmer has spotted substantial call overhead with a small function being called in "hot" loops as shown by the profiler -- or, the function is so tiny that it's about as small as the calling code;-) -- or, inlining the function allows "optimization across function boundaries" that a particular compiler can't spot or can't perform otherwise -- and so forth).
The compiler is free to ignore the hint just as it's free to ignore the older register hint for a variable's storage class (I believe nowadays most optimizing C++ compilers do ignore register but fewer ignore inline) -- IOW, the compiler is free to inline all or some of the calls to a function whether that function is declared inline or not.
(Of course it won't "inline calls" when they're done through an explicit pointer to the function that is stashed away at some points and used at others, or when the function's address is passed as a parameter to some other function - but that might affect the inlining of specific calls, not necessarily other calls to the same function that are done differently).
"Just in case" your compiler takes your inline hints very earnestly, it's often worth measuring code size and speed with and without inline around (unless your compiler offers an option/flag for the purpose, just a #define inline will definitely "disable" the effect of inline and thereby allow such measurement). But if you're going to deploy your code across multiple compilers, esp. for multiple architectures, be aware that the effects that are positive on one platform may end up being counterproductive on another, given the difference in compilers' optimizaiton strategies and in CPU architectures.
what are the requirement for a function so it could be executed inline in c++? is there a case that a function can't be inline?
An inline function is just one where the function call is replaced with the actual code. If you go by that definition, you could copy and paste the code manually and it would be "inline". However, that may not always be a good idea: it's a matter of speed vs. program size. As functions grow larger, the benefit of having them inline reduces.
or any function can be inline and it is the responsibility of the programmer to decide how to define the function, based on run time and compilation-time considerations?
Normally, when you use the inline keyword, it is only a request and the compiler chooses whether or not to actually make the function call inline. Many compilers also provide a way to force a function to be inline (for eg. MSVC has the __forceinline keyword) - in this case, the compiler doesn't try to be smart, so it's up to you to weigh the benefits of making the function inline.
or any function can be inline and it is the responsibility of the programmer to decide how to define the function, based on run time and compilation-time considerations?
It's the compiler that basing on some conditions uses the function as inline function.
inline functions depends upon the length of the code and the complexity of the code...:)
The inline function is just a request to the compiler...
I'm a C/C++ developer, and here are a couple of questions that always baffled me.
Is there a big difference between "regular" code and inline code?
Which is the main difference?
Is inline code simply a "form" of macros?
What kind of tradeoff must be done when choosing to inline your code?
Thanks
Performance
As has been suggested in previous answers, use of the inline keyword can make code faster by inlining function calls, often at the expense of increased executables. “Inlining function calls” just means substituting the call to the target function with the actual code of the function, after filling in the arguments accordingly.
However, modern compilers are very good at inlining function calls automatically without any prompt from the user when set to high optimisation. Actually, compilers are usually better at determining what calls to inline for speed gain than humans are.
Declaring functions inline explicitly for the sake of performance gain is (almost?) always unnecessary!
Additionally, compilers can and will ignore the inline request if it suits them. Compilers will do this if a call to the function is impossible to inline (i.e. using nontrivial recursion or function pointers) but also if the function is simply too large for a meaningful performance gain.
One Definition Rule
However, declaring an inline function using the inline keyword has other effects, and may actually be necessary to satisfy the One Definition Rule (ODR): This rule in the C++ standard states that a given symbol may be declared multiple times but may only be defined once. If the link editor (= linker) encounters several identical symbol definitions, it will generate an error.
One solution to this problem is to make sure that a compilation unit doesn't export a given symbol by giving it internal linkage by declaring it static.
However, it's often better to mark a function inline instead. This tells the linker to merge all definitions of this function across compilation units into one definition, with one address, and shared function-static variables.
As an example, consider the following program:
// header.hpp
#ifndef HEADER_HPP
#define HEADER_HPP
#include <cmath>
#include <numeric>
#include <vector>
using vec = std::vector<double>;
/*inline*/ double mean(vec const& sample) {
return std::accumulate(begin(sample), end(sample), 0.0) / sample.size();
}
#endif // !defined(HEADER_HPP)
// test.cpp
#include "header.hpp"
#include <iostream>
#include <iomanip>
void print_mean(vec const& sample) {
std::cout << "Sample with x̂ = " << mean(sample) << '\n';
}
// main.cpp
#include "header.hpp"
void print_mean(vec const&); // Forward declaration.
int main() {
vec x{4, 3, 5, 4, 5, 5, 6, 3, 8, 6, 8, 3, 1, 7};
print_mean(x);
}
Note that both .cpp files include the header file and thus the function definition of mean. Although the file is saved with include guards against double inclusion, this will result in two definitions of the same function, albeit in different compilation units.
Now, if you try to link those two compilation units — for example using the following command:
⟩⟩⟩ g++ -std=c++11 -pedantic main.cpp test.cpp
you'll get an error saying “duplicate symbol __Z4meanRKNSt3__16vectorIdNS_9allocatorIdEEEE” (which is the mangled name of our function mean).
If, however, you uncomment the inline modifier in front of the function definition, the code compiles and links correctly.
Function templates are a special case: they are always inline, regardless of whether they were declared that way. This doesn’t mean that the compiler will inline calls to them, but they won’t violate ODR. The same is true for member functions that are defined inside a class or struct.
Is there a big difference between "regular" code and inline code?
Yes and no. No, because an inline function or method has exactly the same characteristics as a regular one, most important one being that they are both type safe. And yes, because the assembly code generated by the compiler will be different; with a regular function, each call will be translated into several steps: pushing parameters on the stack, making the jump to the function, popping the parameters, etc, whereas a call to an inline function will be replaced by its actual code, like a macro.
Is inline code simply a "form" of macros?
No! A macro is simple text replacement, which can lead to severe errors. Consider the following code:
#define unsafe(i) ( (i) >= 0 ? (i) : -(i) )
[...]
unsafe(x++); // x is incremented twice!
unsafe(f()); // f() is called twice!
[...]
Using an inline function, you're sure that parameters will be evaluated before the function is actually performed. They will also be type checked, and eventually converted to match the formal parameters types.
What kind of tradeoff must be done when choosing to inline your code?
Normally, program execution should be faster when using inline functions, but with a bigger binary code. For more information, you should read GoTW#33.
Inline code works like macros in essence but it is actual real code, which can be optimized. Very small functions are often good for inlining because the work needed to set up the function call (load the parameters into the proper registers) is costly compared to the small amount of actual work the method does. With inlining, there is no need to set up the function call, because the code is directly "pasted into" any method that uses it.
Inlining increases code size, which is its primary drawback. If the code is so big that it cannot fit into the CPU cache, you can get major slowdowns. You only need to worry about this in rare cases, since it is not likely you are using a method in so many places the increased code would cause issues.
In summary, inlining is ideal for speeding up small methods that are called many times but not in too many places (100 places is still fine, though - you need to go into quite extreme examples to get any significant code bloat).
Edit: as others have pointed out, inlining is only a suggestion to the compiler. It can freely ignore you if it thinks you are making stupid requests like inlining a huge 25-line method.
Is there a big difference between "regular" code and inline code?
Yes - inline code does not involve a function call, and saving register variables to the stack. It uses program space each time it is 'called'. So overall it takes less time to execute because there's no branching in the processor and saving of state, clearing of caches, etc.
Is inline code simply a "form" of macros?
Macros and inline code share similarities. the big difference is that the inline code is specifically formatted as a function so the compiler, and future maintainers, have more options. Specifically it can easily be turned into a function if you tell the compiler to optimize for code space, or a future maintainer ends up expanding it and using it in many places in their code.
What kind of tradeoff must be done when choosing to inline your code?
Macro: high code space usage, fast execution, hard to maintain if the 'function' is long
Function: low code space usage, slower to execute, easy to maintain
Inline function: high code space usage, fast execution, easy to maintain
It should be noted that the register saving and jumping to the function does take up code space, so for very small functions an inline can take up less space than a function.
-Adam
It depends on the compiler...
Say you have a dumb compiler. By indicating a function must be inlined, it will put a copy of the content of the function on each occurrence were it is called.
Advantage: no function call overhead (putting parameters, pushing the current PC, jumping to the function, etc.). Can be important in the central part of a big loop, for example.
Inconvenience: inflates the generated binary.
Is it a macro? Not really, because the compiler still checks the type of parameters, etc.
What about smart compilers? They can ignore the inline directive, if they "feel" the function is too complex/too big. And perhaps they can automatically inline some trivial functions, like simple getters/setters.
Inline differs from macros in that it's a hint to the compiler (compiler may decide not to inline the code!) and macros are source code text generation before the compilation and as such are "forced" to be inlined.
Marking a function inline means that the compiler has the option to include in "in-line" where it is called, if the compiler chooses to do so; by contrast, a macro will always be expanded in-place. An inlined function will have appropriate debug symbols set up to allow a symbolic debugger to track the source where it came from, while debugging macros is confusing. Inline functions need to be valid functions, while macros... well, don't.
Deciding to declare a function inline is largely a space tradeoff -- your program will be larger if the compiler decides to inline it (particularly if it isn't also static, in which case at least one non-inlined copy is required for use by any external objects); indeed, if the function is large, this could result in a drop in performance as less of your code fits in cache. The general performance boost, however, is just that you're getting rid of the overhead of the function call itself; for a small function called as part of an inner loop, that's a tradeoff that makes sense.
If you trust your compiler, mark small functions used in inner loops inline liberally; the compiler will be responsible for Doing The Right Thing in deciding whether or not to inline.
If you are marking your code as inline in f.e. C++ you are also telling your compiler that the code should be executed inline, ie. that code block will "more or less" be inserted where it is called (thus removing the pushing, popping and jumping on the stack). So, yes... it is recommended if the functions are suitable for that kind of behavior.
"inline" is like the 2000's equivalent of "register". Don't bother, the compiler can do a better job of deciding what to optimize than you can.
By inlining, the compiler inserts the implementation of the function, at the calling point.
What you are doing with this is removing the function call overhead.
However, there is no guarantee that your all candidates for inlining will actually be inlined by the compiler. However, for smaller functions, compilers always inline.
So if you have a function that is called many times but only has a limited amount of code - a couple of lines - you could benefit from inlining, because the function call overhead might take longer than the execution of the function itself.
A classic example of a good candidate for inlining are getters for simple concrete classes.
CPoint
{
public:
inline int x() const { return m_x ; }
inline int y() const { return m_y ; }
private:
int m_x ;
int m_y ;
};
Some compilers ( e.g. VC2005 ) have an option for aggressive inlining, and you wouldn't need to specify the 'inline' keyword when using that option.
I won't reiterate the above, but it's worth noting that virtual functions will not be inlined as the function called is resolved at runtime.
Inlining usually is enabled at level 3 of optimization (-O3 in case of GCC). It can be a significant speed improvement in some cases (when it is possible).
Explicit inlining in your programs can add some speed improvement with the cost of an incresed code size.
You should see which is suitable: code size or speed and decide wether you should include it in your programs.
You can just turn on level 3 of optimization and forget about it, letting the compiler do his job.
The answer of should you inline comes down to speed.
If you're in a tight loop calling a function, and it's not a super huge function, but one where a lot of the time is wasted in CALLING the function, then make that function inline and you'll get a lot of bang for your buck.
First of all inline is a request to compiler to inline the function .so it is upto compiler to make it inline or not.
When to use?When ever a function is
of very few lines(for all accessors
and mutator) but not for recursive
functions
Advantage?Time taken for invoking the function call is not involved
Is compiler inline any function of its own?yes when ever a function is defined in header file inside a class
inlining is a technique to increase speed. But use a profiler to test this in your situation. I have found (MSVC) that inlining does not always deliver and certainly not in any spectacular way. Runtimes sometimes decreased by a few percent but in slightly different circumstances increased by a few percent.
If the code is running slowly, get out your profiler to find troublespots and work on those.
I have stopped adding inline functions to header files, it increases coupling but gives little in return.
Inline code is faster. There is no need to perform a function call (every function call costs some time). Disadvantage is you cannot pass a pointer to an inline function around, as the function does not really exist as function and thus has no pointer. Also the function cannot be exported to public (e.g. an inline function in a library is not available within binaries linking against the library). Another one is that the code section in your binary will grow, if you call the function from various places (as each time a copy of the function is generated instead of having just one copy and always jumping there)
Usually you don't have to manually decide if a function shall be inlined or not. E.g. GCC will decide that automatically depending on optimizing level (-Ox) and depending on other parameters. It will take things into consideration like "How big is the function?" (number of instructions), how often is it called within the code, how much the binary will get bigger by inlining it, and some other metrics. E.g. if a function is static (thus not exported anyway) and only called once within your code and you never use a pointer to the function, chances are good that GCC will decide to inline it automatically, as it will have no negative impact (the binary won't get bigger by inlining it only once).