Sign in to follow this  

inline functions. Pros and Cons

This topic is 3203 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

I am learning C++ and I am not sure what the benefits of using inline functions are. What exactly are they used for? So far I can only guess that they are used when you have really small functions that are repetedly used. Other than that what good are they?

Share this post


Link to post
Share on other sites
It's a hint to the compiler to place the code inline instead of doing a jmp statement and calling function logic centralized elsewhere in the exe. For some simple operations (vector math and such) this can result in a pretty nice speedup of your code.

But, if you're not really sure what it's good for, it's unlikely that you're writing code complicated enough to benefit from it. Until you get to a point where you need to start optimizing your first game/application I wouldn't worry about it.

-me

Share this post


Link to post
Share on other sites
Ok thank you for the help. So all inlining a function does is tell the compiler that instead of making a function call, it should copy the exact code wherever the function is called. Your right I don't see myself doing anything that time important yet, but it is nice to know. As they say you never know when some little tidbit of knowledge will make a difference.

Share this post


Link to post
Share on other sites
In order to understand why they can (and can't) be helpful, you have to understand how they work.

Now, normally when you call a function in C and derivatives, what ends up happening is that your CPU is sent an instruction to put whatever arguments the function takes into certain registers and then jump to a specific point in the machine code of your executable. Then the little code block is executed, (whatever you specified in your program) the result (if there is one) is placed in another register, and the program jumps back to where it was before and continues.

Obviously, this can be a waste of time if your function is only a line or two. You spend as much time actually calling the function (and *technically* getting nothing done) as you do actually working with your data. This is pretty clearly a bad thing.

Inlining a function tells the compiler "screw moving to another point in my code, just put the contents of the function right smack wherever I call it." The effect is twofold:
1- There's no overhead for calling the function. Bing, data gets processed, program moves on.
2- The program gets bigger, and this is where it gets tricky. In addition to loading, storing and manipulating *data,* your processor actually needs to load *what to do with said data.* Literally, it picks up machine code in much the same way it picks up the contents of an integer or a float. The problem with bigger executables (and by extension, rampant inlining) is that this happens more frequently. In addition, this load and store of program code is actually more expensive than just setting the value of a float or whatever. Thus, if you inline too much, your program stands a very real chance of being slower than it was before.

Share this post


Link to post
Share on other sites
I don't know whether or not this is sound advice, but after all that I've read about compilers being free to ignore your inlining suggestions, or inlining functions without being told to do so ... or your inlining even having the potential to HURT performance, I generally shy away from using inline and simply pretend it doesn't exist at all. I'll trust the compiler to know best when to optimize a function call by inlining it and when not to.


EDIT: Fixed spelling / grammar.

[Edited by - Red Ant on March 11, 2009 6:04:04 PM]

Share this post


Link to post
Share on other sites
Quote:
Original post by Red Ant
I don't know whether or not this sound advice, but after all that I've read about compilers being free to ignore your inlining suggestions, or inlining functions without being told do so ... or your inlining even having the potential to HURT performance, I generally shy away from using inline and simply pretend it doesn't exist at all. I'll trust the compiler to know best when to optimize a function call by inlining it and when not to.
It's a little more devious than that, actually. Compilers are just plain better at deciding what should and should not be inlined than a human being is. With this said, compilers that handle compilation units disjointedly [or are configured to handle compilation units disjointedly] will not inline functions that do not have function bodies within that compilation unit. Specifying something as 'inline' doesn't force it to be inlined, but what it does do is force you to supply said function body in the header, thus making the function body available within any compilation unit for potential inlining. So while it is true that the compiler is free to inline whatever it feels like, and ignore your 'suggestion' entirely [note that there are mechanisms to either force or restrict inlining, but this isn't the topic of this thread], it will not inline functions whose definitions are found in disjoint sections of your code.

To put it simply, if your compiler handles compilation units disjointedly: anything in any .h/.hpp file is inline-able anywhere. Anything defined in a .cpp file is inlinable if used within that same .cpp file. Anything that is defined in one .cpp file and used in another will not be inlined [this is a rather rough specification, and there are some gotcha's here, but this is a ballpark estimate of how it works]. By marking something 'inline', you are required to provide a function body within the .h/.hpp file, and thus this function is made an inline candidate.

While inlining something sometimes makes your program larger, marking it as 'inline' does not. It doesn't make your program larger because anything that would benefit from being inlined, would have been inlined anyway, and anything that would have just added bulk to your program would not have been inlined [even if marked, 'inline'].

Now, some compilers offer 'whole program optimization' [or something similarly named, but in VC++ it is called 'whole program optimization'], which makes this a moot point entirely. This make all your functions and their definitions available to all sections of code, while allows for inlining of things that are not completely provided in the header [which is why this option is so great to have]. You'd be totally mad to not compile anything that is meant as a release build without whole program optimization turned on [supposing that you are using a compiler that supports it], as this really can make a huge difference, but makes compilation time painfully long, which is why you don't do it for debug builds.

Should also be noted that all of the above is for C/C++ only, and other languages have their own restrictions and conventions with respect to inlining. Virtually every compiler and many interpreters for any languages inlines.

Long story short though, don't worry about it. Let the computer do the heavy lifting for junk like this.

[Edited by - Drigovas on March 11, 2009 6:59:03 PM]

Share this post


Link to post
Share on other sites
A couple of things that I have found when using the inline keyword :

It can increase dependancies between files (which in turn can lead to larger compilation times), for example, you can't do this :


// SomeHeader.h
void someFunction(class SomeClass& someObject);



If you wanted to make this function inline you would have to include the file that defined SomeClass, so that SomeHeader.h then depends on SomeClass.h

Drigovas mentions whole program optimisation, which is a very good point, however under msvc++, if the function to be called is in a .lib then the functions won't be inlined, even with link time code generation turned on. I don't know why it has just never worked for me.

So I would pretty much agree with everyone else, it's probably not worth worrying about, the compiler will do most of the work for you. The only time I use the inline keyword now is when I have a function that is part of a .lib and profiling suggests it would benefit from being inlined.

Share this post


Link to post
Share on other sites
Quote:
Original post by _moagstar_
If you wanted to make this function inline you would have to include the file that defined SomeClass, so that SomeHeader.h then depends on SomeClass.h


Are you sure about that?? That seems dodgy to me. IMO as long as you at least forward declare SomeClass, you should be fine.

Share this post


Link to post
Share on other sites
Quote:
Original post by Red Ant
Quote:
Original post by _moagstar_
If you wanted to make this function inline you would have to include the file that defined SomeClass, so that SomeHeader.h then depends on SomeClass.h


Are you sure about that?? That seems dodgy to me. IMO as long as you at least forward declare SomeClass, you should be fine.

If you make the function inline, you need to provide the full definition for the function. If you need the full definition of the function, you also need the full definition of the class in order to access its content.

Share this post


Link to post
Share on other sites
Quote:
Original post by _moagstar_
Drigovas mentions whole program optimisation, which is a very good point, however under msvc++, if the function to be called is in a .lib then the functions won't be inlined, even with link time code generation turned on. I don't know why it has just never worked for me.


I am pretty sure you are wrong about this, as I can control projects linking time by toggling LTCG on or off for specific libraries.

And for the topic of inline, I'd rather let compiler figure out what to inline. With exception of, last profiler runs before golding the product, if there are some one line getter functions which show up and take >1% of time..

Share this post


Link to post
Share on other sites
Interesting to note, I once build a Vector3 class using MVC6 having inline for the arithmetic methods. But even in release mode, the compiler refused to inline the methods (assembler inspection). Then, I used the keyword __forceinline instead, and this gave a really significant speedup. I don't know how this translates to more recent compilers, but be careful, your compiler might be stubborn!

Share this post


Link to post
Share on other sites
Quote:
Original post by Red Ant
Are you sure about that??


Give it a go if you don't believe me. I guess technically if the function didn't actually do anything with the class it would work, but then there doesn't seem to be much point in that.

Quote:
Original post by Ftn
I am pretty sure you are wrong about this, as I can control projects linking time by toggling LTCG on or off for specific libraries.


It wouldn't be the first time I've been wrong, and won't be the last...perhaps you're doing something with the linker settings that I'm not, but with msvc++ 2008 and /lctg option it certainly isn't inlining statically linked functions for me. If you are able to get it to work then I'd be interested to hear how.

Share this post


Link to post
Share on other sites
In our company, we consider inlining as a premature optimization. So we don't do it unless the app didn't meet efficiency requirements (60fps for games). I'm not sure what's the reason, though. I just remember the boss saying the debugger/profiler won't be able to work well if there are too many inlined stuff (these includes macros).

Share this post


Link to post
Share on other sites
Unlike what has been said, "inline" is not just a hint to the compiler.
It changes the semantics of symbols, too, in a similar way to extern/static, so that defining them in headers, and thus multiple times, doesn't lead to issues.

Note that member functions defined in a class definition are implicitly inline.

Share this post


Link to post
Share on other sites
Quote:
Original post by mazelle
In our company, we consider inlining as a premature optimization. So we don't do it unless the app didn't meet efficiency requirements (60fps for games). I'm not sure what's the reason, though. I just remember the boss saying the debugger/profiler won't be able to work well if there are too many inlined stuff (these includes macros).

If you force inline stuff prematurely, you cannot tell with profiler if the function is good choice for inlining. You might actually make the program slower.

Also forcing it prevents compiler to inline function in select few places where it is actually good to do so (as opposed to everywhere). And I believe compiler can do partial inlining too. All in all, compilers usually optimize larger scale programs better than programmers.

Share this post


Link to post
Share on other sites

This topic is 3203 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this