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?
+2
A:
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.
wheaties
2009-12-09 18:44:33
A:
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.
jldupont
2009-12-09 18:46:07
+4
A:
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.
Ned Batchelder
2009-12-09 18:46:56
inline everything? ;) -- except `main()`
pmg
2009-12-09 18:52:01
It may hurt, if the cache misses due to code blow-up do slow down more as omitting the function call overhead does speed up.
drhirsch
2009-12-09 19:51:06
I never advocated inlining everything. What I meant was, if you know you want a function inlined, and you put the `inline` keyword on it, then it won't hurt your chances of getting it inlined. How you decide you want it inlined is an entirely other matter.
Ned Batchelder
2009-12-09 20:39:04
I refer to the "It certainly doesn't hurt". This can easily be misunderstood as "inlinig certainly doesn't hurt", which is of course not correct.
drhirsch
2009-12-10 08:50:40
A:
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 :)
pmg
2009-12-09 18:50:23
A:
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.
David Thornley
2009-12-09 18:57:51
+5
A:
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.
Mark Ransom
2009-12-09 18:59:02
inline is just a nice thing to do inside of .h files. the controller of linkage is `static` though. Any functions in header files I create are always `static inline`
Earlz
2009-12-09 20:17:12
The linkage of a non-static inline function is still external. The address is the same in each TU, and local static objects also have the same identity in each TU. It's still *the same* function. Explained in more detail here: http://stackoverflow.com/questions/908830/isnt-cs-inline-totally-optional/910686#910686
Johannes Schaub - litb
2009-12-09 20:31:13
@litb Thanks, I seem to have missed that one. I'll have to go away and digest it.
anon
2009-12-09 20:39:07
A:
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++.
Justin
2009-12-09 19:15:42
+2
A:
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.
Crashworks
2009-12-09 20:12:32