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.

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.

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.

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.

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.

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

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.

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

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.

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++.