Why so many 'inline' ?

[Ummon]

I just take a look in the bitcoin source code and I find tons of inline functions/methods. Usually, inlining is a very bad idea, it can decrease performance. Inlining should only be made if necessary and should be benchmarked to check if there is some gain.

What do you think?

[1714168658]

1714168658

[1714168658]

1714168658

[sandos]

Well, I thought modern compilers just took that as a hint, and they don't always respect it. I could be wrong though.

[Nesetalis]

some times the case, but its also harder to read and maintain.

[wumpus]

Well, I thought modern compilers just took that as a hint, and they don't always respect it. I could be wrong though.

Indeed, a modern compiler will choose to inline when it makes sense, no matter whether the developer provides a hint or not (this is especially true with whole-program optimisation).

[realnowhereman]

Some points about 'inline'.

• inlining is not a universally "bad idea", it certainly won't decrease performance.  It might significantly increase object size.
• It isn't the case that the "inline" keyword is used to tell the compiler to inline code (bizarrely).
• It's use is mandatory when it is needed, and a noop when it is not.
• It is used to allow you to put member function definitions outside the class declaration in header files that are included from multiple locations.  If you do not include it, then the second module that includes it will generate a linker error as it finds multiple definitions for the same function.

Code:

class SomeClass {
  void someInline( int y ) { x = y; }
  int x;
};

is exactly the same as

Code:

class SomeClass {
  void someInline( int );
  int x;
};

inline void SomeClass::someInline( int y )
{
  x = y;
}

• inline on a virtual member is ignored. It's impossible to have an inline virtual.
• inline in the module and not the header will either give linker errors (when other modules don't find the exported symbol, or be ignored.
• Finally: inlining can be dangerous during multiple compile cycles if the function changes if dependent modules are not recompiled, since the old version of the function could have been inlined into another module, and you end up with module A having inlined version1 and module B inlined version2.
• Declaring a function 'static' in a C program when that function is not declared in the header means that the symbol is not exported, and allows the compiler to inline as it see fit.  'inline' is utterly unnecessary to make the function be inlined.
  

HTH.

[xf2_org]

• inlining is not a universally "bad idea", it certainly won't decrease performance.  It might significantly increase object size.

Incorrect.  Increasing code size decreases cache hit rate, decreasing performance.

• Finally: inlining can be dangerous during multiple compile cycles if the function changes if dependent modules are not recompiled, since the old version of the function could have been inlined into another module, and you end up with module A having inlined version1 and module B inlined version2.

This is just silly.  If this occurs, there is a bug in your build system.

No serious programmer worries about this.

• Declaring a function 'static' in a C program when that function is not declared in the header means that the symbol is not exported, and allows the compiler to inline as it see fit.  'inline' is utterly unnecessary to make the function be inlined.
  

These two statements don't match up.  If you want to "make" (force) the function be inlined, then you obviously do not wish to leave that decision to the compiler.

[goatpig]

Incorrect.  Increasing code size decreases cache hit rate, decreasing performance.

On the other hand inlining in a heavy duty loop will limit code jumps and thus pipeline flushing.

[Gavin Andresen]

My rule of thumb is "never inline methods more than 1 line long."

Unless you're doing something super performance-critical, in which case my rule of thumb is "don't change anything until after you've written a realistic benchmark."

But I'm an old-fashioned C++ coder, kids these days seem to want to put all the code in .hpp files.

[Jim Hyslop]

Some points about 'inline'.

• inline on a virtual member is ignored. It's impossible to have an inline virtual.

If the compiler can determine the dynamic type of an object at compile time, then it most certainly can omit virtual lookup, and either call the function directly or unroll it inline if it so chooses.

Consider this code:

Code:

class base
{
public:
    virtual void SomeFunction()
    {
        cout << "In base::SomeFunction" << endl;
    }
};

class derived : public base
{
public:
    virtual void SomeFunction()
    {
        cout << "In derived::SomeFunction" << endl;
    }
};

void f()
{
    derived d;
    d.SomeFunction();
}

The compiler can optimize f() any way it sees fit. In fact, it could compile the code as if you had written:

Code:

void f()
{
    cout << "In derived::SomeFunction" << endl;
}

since there is no observable difference between that and what you wrote.

Edit: minor edit to clean up mis-matched 'list' tags

[wumpus]

• inlining is not a universally "bad idea", it certainly won't decrease performance.  It might significantly increase object size.

Incorrect.  Increasing code size decreases cache hit rate, decreasing performance.

Not always. It depends on whether the code fit in the cache in the first place. Or whether it no longer fits with the inlining. The corollary: decreasing code size certainly doesn't always increase performance.

• Finally: inlining can be dangerous during multiple compile cycles if the function changes if dependent modules are not recompiled, since the old version of the function could have been inlined into another module, and you end up with module A having inlined version1 and module B inlined version2.

This is just silly.  If this occurs, there is a bug in your build system.

No serious programmer worries about this.

Include files aren't always properly declared as dependencies in makefiles. I can tell you from firsthand that bugs do happen because of this. A bug in your build file is still a bug. This isn't an argument against inlining though, just a reason to be careful.

• Declaring a function 'static' in a C program when that function is not declared in the header means that the symbol is not exported, and allows the compiler to inline as it see fit.  'inline' is utterly unnecessary to make the function be inlined.
  

These two statements don't match up.  If you want to "make" (force) the function be inlined, then you obviously do not wish to leave that decision to the compiler.

You can specify the inline keyword, but the compiler won't necessarily listen to you. Some compilers to have special pragmas to force inlining, but they are not a part of the C++ standard.

[/list]