Benefits of declaring a function as “inline”?

问题:

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 adding it then, or should I just rely on the compiler knowing better than me?

回答1:

There are two reasons to use the inline keyword. One is an optimization hint, and you can safely ignore it; your compiler is like to ignore it too. The other reason is to allow a function to exist in multiple translation units, and that usage is strictly necessary. If you put a function into a .h header file for example, you'd better declare it inline.

回答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.

回答3:

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.

回答4:

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.

回答5:

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.

回答6:

You can't be absolutely sure the compiler will catch the "critical" sections of your code: use "inline" when you know it matters.

A compiler isn't a profiler.

回答7:

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 :)

回答8:

Since it's only a hint to the compiler, the compiler is free to ignore it, and likely will. The compiler has a lot of relevant information you don't have, such as how much of a cache line a loop will take up, and can inline or not on a case-by-case basis.

It's just a hint, so using it is unlikely to hurt anything. You almost certainly should avoid any compiler-specific things that force functions to be inlined or not inlined.

回答9:

The declaration is pretty much useless and quite different from the original intent. Compilers have taken much more liberty wrt what and what not to inline (IMO).

It's a hint to the compiler, using it will help you and have the intended significance only sometimes.

If you need to write performance critical programs, do not rely on the compiler (knowledge of performance & optimization is not learned in a day). There's usually a way to override the compiler's judgement (not just hint at your preference), to force inlining. This is the way I declare a function/method inline, more than 95% of the time (knowing also when it is implicit). If/When you know you'd need to know how to inline properly, then employ force-inlining as well, but do learn when and how to use it.

Inlining is not a silver bullet to better performance; it can have negative effects. Abuse of inlining can have some scary consequences in extreme cases, but usually performance is a little worse and binaries are larger when used improperly. Proper use of inlining can have considerably positive results.

Inlining is also helpful to remove symbols which would otherwise be exported, reducing the binary, depending on the number of instances and size.

Another thing: You'll get different linkage with C++.

回答10:

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);