I'm a C/C++ developer, and here are a couple of questions that always baffled me.
Thanks
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.
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.
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.
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.
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.
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?
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.
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.
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.
- 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.
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.
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.
Take a look at this question in regard to inlining code and the tradeoffs concerned.
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).
As has been suggested in previous answers, inline can make code faster, often at the expense of increased executables. However, modern compilers are very good at inlining automatically without any prompt from the user when set to high optimization. Actually, compilers are usually better at determining what 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 the function is hard to inline (i.e. using nontrivial recursion or function pointers) but also if the function is simply too large to be meaningfully inlined.
However, declaring a function inline may actually be necessary for completely different reasons, namely to satistfy 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 marking it static (static – the keyword with the most completely unrelated meanings in C).
However, it's often better to mark a function inline instead. Thus, you allow the compiler to not create the function definition at all. This is often very useful when working with templates which usually have to be declared in header files.
As an example, consider the following program:
// header.hpp
#include <iosfwd> // for std::ostream&
#ifndef HEADER_HPP
#define HEADER_HPP
template <typename IteratorT>
/*inline*/ void print_all(IteratorT begin, IteratorT end, std::ostream& out, char sep = ' ') {
while (begin != end)
out << *begin++ << sep;
}
#endif // !defined(HEADER_HPP)
// test.cpp
#include <iostream>
#include <vector>
#include "header.hpp"
void test_function() {
using namespace std;
vector<int> vec;
int x;
while (cin >> x) vec.push_back(x);
cout << "Results: ";
print_all(vec.begin(), vec.end());
cout << endl;
}
// main.cpp
#include <iostream>
#include <vector>
#include "header.hpp"
void test_function(); // Forward declaration.
int main() {
using namespace std;
vector<int> xyz(23, 42);
print_all(xyz);
cout << endl << "Test call:" << endl;
test_function();
}
Notice that both .cpp files include the header file and thus the function definition of print_all. 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 unit, say, using the following command:
$ g++ -Wall -pedantic main.cpp test.cpp
you'll get an error saying “duplicate definition of print_all” or something similar. If, however, you unquote the inline modifier in front of the function definition, the code compiles and links correctly.