Jump to content
  • Advertisement
Sign in to follow this  
steveworks

inline functions. Pros and Cons

This topic is 3418 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
Advertisement
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
Thanks for the replies. I am pretty sure I understand inline functions at least mostly now. Now to move on to the next page. dun dun dun.:)

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
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!