views:

2518

answers:

11

While it would be very convenient to use inline functions at some situations,

Are there any drawbacks with inline functions?

Conclusion:

Apparently, There is nothing wrong with using inline functions.

But it is worth noting the following points!

  • Overuse of inlining can actually make programs slower. Depending on a function's size, inlining it can cause the code size to increase or decrease. Inlining a very small accessor function will usually decrease code size while inlining a very large function can dramatically increase code size. On modern processors smaller code usually runs faster due to better use of the instruction cache. - Google Guidelines

  • The speed benefits of inline functions tend to diminish as the function grows in size. At some point the overhead of the function call becomes small compared to the execution of the function body, and the benefit is lost - Source

  • There are few situations where an inline function may not work:

    • For a function returning values; if a return statement exists.
    • For a function not returning any values; if a loop, switch or goto statement exists.
    • If a function is recursive. -Source
  • The __inline keyword causes a function to be inlined only if you specify the optimize option. If optimize is specified, whether or not __inline is honored depends on the setting of the inline optimizer option. By default, the inline option is in effect whenever the optimizer is run. If you specify optimize , you must also specify the noinline option if you want the __inline keyword to be ignored. -Source

+2  A: 

I doubt it. Even the compiler automatically inlines some functions for optimization.

Vaibhav
+9  A: 

It could increase the size of the executable, and I don't think compilers will always actually make them inline even though you used the inline keyword. (Or is it the other way around, like what Vaibhav said?...)

I think it's usually OK if the function has only 1 or 2 statements.

Edit: Here's what the linux CodingStyle document says about it:

Chapter 15: The inline disease

There appears to be a common misperception that gcc has a magic "make me faster" speedup option called "inline". While the use of inlines can be appropriate (for example as a means of replacing macros, see Chapter 12), it very often is not. Abundant use of the inline keyword leads to a much bigger kernel, which in turn slows the system as a whole down, due to a bigger icache footprint for the CPU and simply because there is less memory available for the pagecache. Just think about it; a pagecache miss causes a disk seek, which easily takes 5 miliseconds. There are a LOT of cpu cycles that can go into these 5 miliseconds.

A reasonable rule of thumb is to not put inline at functions that have more than 3 lines of code in them. An exception to this rule are the cases where a parameter is known to be a compiletime constant, and as a result of this constantness you know the compiler will be able to optimize most of your function away at compile time. For a good example of this later case, see the kmalloc() inline function.

Often people argue that adding inline to functions that are static and used only once is always a win since there is no space tradeoff. While this is technically correct, gcc is capable of inlining these automatically without help, and the maintenance issue of removing the inline when a second user appears outweighs the potential value of the hint that tells gcc to do something it would have done anyway.

yjerem
In VC++ it will increase the size, not sure about other compilers. But if they do chose to make it inline I'm sure it would make it larger too.
Brian R. Bondy
by they I mean the compiler in question.
Brian R. Bondy
Yes, the size increment was the major one i heard of.. curious to know if there are more!
Prakash
A: 

Excessive inlining of functions can increase size of compiled executable which can have negative impact on cache performance, but nowadays compiler decide about function inlining on their own (depending on many criterias) and ignore inline keyword.

Mladen Jankovic
+2  A: 

I'd amplify what @Vaibhav said, and declare that "inline" is the "register" of the 2000s. Remember the "register" keyword? Has anybody used it since the 1980s?

Paul Tomblin
+8  A: 

It worth pointing out that the inline keyword is actually just a hint to the compiler. The compiler may ignore the inline and simply generate code for the function someplace.

The main drawback to inline functions is that it can increase the size of your executable (depending on the number of instantiations). This can be a problem on some platforms (eg. embedded systems), especially if the function itself is recursive.

I'd also recommend making inline'd functions very small - The speed benefits of inline functions tend to diminish as the function grows in size. At some point the overhead of the function call becomes small compared to the execution of the function body, and the benefit is lost.

Alan
+1  A: 

You should also note that the inline keyword is only a request. The compiler may choose not to inline it, likewise the compiler may choose to make a function inline that you did not define as inline if it thinks the speed/size tradeoff is worth it.

This decision is generaly made based on a number of things, such as the setting between optimise for speed(avoids the function call) and optimise for size (inlining can cause code bloat, so isn't great for large repeatedly used functions).

with the VC++ compiler you can overide this decision by using __forceinline

SO in general: Use inline if you really want to have a function in a header, but elsewhere theres little point because if your going to gain anything from it, a good compiler will be making it inline for you anyway.

Fire Lancer
+3  A: 

I agree with the other posts:

  • inline may be superfluous because the compiler will do it
  • inline may bloat your code

A third point is it may force you to expose implementation details in your headers, .e.g.,

class OtherObject;

class Object {
public:
    void someFunc(OtherObject& otherObj) {
        otherObj.doIt(); // Yikes requires OtherObj declaration!
    }
};

Without the inline a forward declaration of OtherObject was all you needed. With the inline your header needs the definition for OtherObject.

maccullt
I don't believe in practice your first bullet is correct. The compiler is OK to *ignore* inline but it only has the option if the definition of the function is visible at the call site and that more or less limits you to functions local to the current TU.
Richard Corden
+1  A: 

Inlining larger functions can make the program larger, resulting in more cache misses and making it slower.

Deciding when a function is small enough that inlining will increase performance is quite tricky. Google's C++ Style Guide recommends only inlining functions of 10 lines or less.

Nick
+2  A: 

As others have mentioned, the inline keyword is only a hint to the compiler. In actual fact, most modern compilers will completely ignore this hint. The compiler has its own heuristics to decide whether to inline a function, and quite frankly doesn't want your advice, thank you very much.

If you really, really want to make something inline, if you've actually profiled it and looked at the disassembly to ensure that overriding the compiler heuristic actually makes sense, then it is possible:

  • In VC++, use the __forceinline keyword
  • In GCC, use __attribute__((always_inline))

The inline keyword does have a second, valid purpose however - declaring functions in header files but not inside a class definition. The inline keyword is needed to tell the compiler not to generate multiple definitions of the function.

Niall
You probably mean "defining" functions in header files rather than declaring.
Richard Corden
The definition must be available in order for the compiler to decide if it will inline the function or not. Intra-TU this requires that the definitions be visible in the header file - which requires the 'inline' keyword. It therefore brings us back to the developer having to make the call.
Richard Corden
+2  A: 

There is a problem with inline - once you defined a function in a header file (which implies inline, either explicit or implicit by defining a body of a member function inside class) there is no simple way to change it without forcing your users to recompile (as opposed to relink). Often this causes problems, especially if the function in question is defined in a library and header is part of its interface.

+1  A: 

I don't know if my answer's related to the question but:

Be very careful about inline virtual methods! Some buggy compilers (previous versions of Visual C++ for example) would generate inline code for virtual methods where the standard behaviour was to do nothing but go down the inheritance tree and call the appropriate method.

Stacker