Benefits of declaring a function as “inline”?

Question

Every time I read about the \"inline\" declaration in C it is mentioned that it is only a hint to the compiler (i.e. it does not have to obey it). Is there any benefit to ad

Answer 1

The C++ FAQ has good info on this. I prefer to use the inline function as it gives the compiler more information about what I would "like" it to do. Whether or not the compiler ends up inlining it is up to it, but giving it a little help won't hurt.

Answer 2

Compilers are smart, but can still benefit from hints from the developer. If you think some of your functions in particular should be inlined, then declare them as such. It certainly doesn't hurt.

Answer 3

The difference isn't likely to matter.

Leave inline out until you measure the code performance and determine that you could gain some performance by inlining a specific function that the compiler chose to treat as normal. Even then, there's no guarantee the compiler will inline that function, but at least you did all you could :)

Answer 4

It provides a simple mechanism for the compiler to apply more OPTIMIZATIONS.
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);

Answer 5

Generally modern compilers will "inline" things they deem important. I'd let it handle it for you.

Edit:

After reading what others have written, you know what? I think I'd let it handle most of the inlining THEN profile your code and THEN inline functions which are bottlenecks. My advise is slightly colored by a certain developer I work alongside who pre-optimizes all his code. Half the time I need to spend 5 min. just figuring out what is trying to be accomplished.

Answer 6

Like everyone else has said, the keyword is only a hint, but it's a hint most compilers take pretty seriously. Also, most compilers are very bad at inlining functions from different compilation units -- if you define Foo() in file a.c, but call it in b.c, odds are pretty slim that it will intelligently inline b.c's calls to Foo(). (in fact, it won't happen at all without LTCG.) so it's worth using when you're sure a function really needs to be inlined. That's a decision best made with empirical timings.

For example, on my platform I measured the difference between an inline and a direct (nonvirtual) function as about 5 nanoseconds, so my rule of thumb is that I inline functions that should take less than ten cycles: trivial accessors and the like. Other specific functions get inlined afterwards when my profiler tells me that I'm wasting a lot of time in the overhead of calling them.