Printable View
I've seen statements such as, "when the compiler tries to inline the function.." a few times, but do not understand what inlining means. I googled the term, but did not find an explanation that was geared towards a novice such as myself. If it's not too much trouble, can someone explain what it means? Thanks in advance!
The way I think of inlining is replacing the function call with the given code eg.
So in this case this would really be thisCode:#include <iostream>
inline void printHello()
{
std::cout<<"Hello"<<std::endl;
}
int main()
{
printHello();
std::cin.get();
return 0;
}
Code:#include <iostream>
inline void printHello()
{
std::cout<<"Hello"<<std::endl;
}
int main()
{
std::cout<<"Hello"<<std::endl;//printHello()
std::cin.get();
return 0;
}
That was a great example. Now, my next question is when should inlining be used? What are the implications of using inlining? I can see that you wouldn't really want to use inlining when you have a helper method that has multiple references, but when would you want to? Thanks.
My guess is if you need the function to be called quickly with no overhead. However, the compiler still has the last say whether or not the function will be inlined or not.
You start using inline only after you have a well written, working program. Then you can worry about the optimzation.Quote:
Originally Posted by codegeek
inlining pros (not complete) :
Can speed up execution
*could* *possibly* reduce code size in some very specific cases
cons (not complete):
Usally increases code size
Makes it harder to debug (which is why you wait till you have the working program)
I seem to recall the inline keyword is only suggestive as well, in the end the compiler may disagree with you and leave the code as is. Or it may inline smaller functions where it will benefit the compiler.
Yes inline is a suggestion just like register. And during optimization the compiler might very well inline functions that are smaller then the function call overhead. Still both should only be invoked after the program is working (and you've made lots of backups of the source)
Let's say prog-man's program grows a little... let's say we call PrintHello() ten times -
If we don't use inline, the compiler will generate the machine code for PrintHello() only once. Each time we call PrintHello(), the program will branch (detour) to the function.
If we inline (and if the compiler likes the suggestion) the machine code for PrintHello() will be replicated "in-line" 10 times, and the program won't have to branch-to the function.
The program (exe file) will be longer, but it will run faster because it doesn't have the branching overhead.
> The program (exe file) will be longer, but it will run faster because it doesn't have the branching overhead.
Or it will run slower, because it has to fetch the same code 9 times out of uncached memory, rather than re-using the single copy which is already in cache as a result of the first call.
http://www.pcguide.com/ref/cpu/arch/...ulative-c.html
If your processor implements these, then branching could be a lot less expensive than may be apparent from the code.
> Now, my next question is when should inlining be used?
1. Never
2. Not yet
As Thantos said, "You start using inline only after you have a well written, working program."
It's a waste of effort trying to second-guess what hurts performance and what doesn't, so the best thing to do up-front is largely ignore it and concentrate on writing good clear programs.
http://vision.eng.shu.ac.uk/bala/c/c...imization.html
If you manage the first two points, you're off to a good start.
Then (when you've finished) you measure the performance to determine if in fact anything needs to be done at all.
If you decide something needs to be done, then you can use a profiler and make controlled changes to the code to determine how effective your "improvements" were.
I've never found an occasion where inlining helped me noticeably
You can always tell your compiler to inline every call it finds suitable and leave everything to it.
:D I knew I was sticking my neck out by making an absolute statement! :DQuote:
Or it will run slower...
Of course you know, Salem, that branch prediction shtuff only applies to conditional branching. :)
I've never used inline. In my opinion if you need that much control... and if you think you can optimize better than the compiler, you should write (that part of) the code in assembly.
That's hardly the point in the specific optimization inline gives you, though.Code:you should write (that part of) the code in assembly.
inline is a native part of C++ because object-orientation is very prone to having miniscule functions. Just look at, for example, the c_str() implementation of the string class someone posted here somewhere:
In this case, and in most getters' cases, the essential function code is actually shorter than the function call. (In the most conservative x86 case, the function call involves a push, a call, several pushes to, ermm, preserve registers, then popping these registers off again and doing a ret, followed by a substraction in esp to clean the stack. The function code, placed after the preservation of the registers, is one mov to get the this pointer into a register and a second mov to get the member into eax.) This is where inlining really makes sense. Even if you wanted, you couldn't "inline" this function yourself, not without completely breaking object-oriented design principles (by making str a public member).Code:class strink {
char *str;
public:
const char * c_str() const;
};
const char * strink::c_str() const
{
return str;
}