8

With modern compilers, does declaring a function inline have any effect on performance anymore?

That is, faced with the option of defining a function inline in the header or in the source file, is there any difference between the two?

In this SO question, When to use inline function and when not to use it?, the accepted answer gives several reasons.

An excerpt:

do:

  • very small functions are good candidates for inline: faster code and smaller executables (more chances to stay in the code cache)
  • the function is small and called very often

don't:

  • large functions: leads to larger executables, which significantly impairs performance regardless of the faster execution that results from the calling overhead

The advice is from 7 years ago, and I've read that these days the inline word is ignored, and the compiler decides what to inline.

Questions:

  • Is the above advice still relevant?
  • To what extent does defining a function inline have any effect (other than to prevent multiple definition linker issues)?
  • What reasons do I have to inline a function these days?
Community
  • 1
  • 1
Steve Lorimer
  • 27,059
  • 17
  • 118
  • 213
  • Last I checked (admittedly some years ago) g++ was very much guided or almost forced by `inline`, and applied little free will to the decision. That's a problem because for header only modules the `inline` isn't meant as a hint to inline calls. Happily it's a problem that can be ignored in practice. **Measure** whether the code is too slow. If it is, optimize. – Cheers and hth. - Alf Oct 31 '16 at 18:20
  • The `inline` *keyword* doesn't guarantee inlining, and inlining can happen without it. So it may make more sense to remove the `inline` keyword from the question entirely. – juanchopanza Oct 31 '16 at 18:20
  • @juanchopanza ok, agreed, I'll update the question – Steve Lorimer Oct 31 '16 at 18:23
  • The title says "inlining functions", but the body says "declaring a function inline". Which is it? The two have very little relationship nowadays, as has already been mentioned. – Lightness Races in Orbit Oct 31 '16 at 18:25
  • @Cheersandhth.-Alf ok, but the question relates to when you do have a choice (ie: *not* header-only libraries)... and as such, if I **don't** inline a small and oft-called function, could it have an adverse performance impact, or would gcc decide to inline it anyway? – Steve Lorimer Oct 31 '16 at 18:26
  • _You_ never inline or not-inline a thing. Only your compiler makes that choice. Your only choice is whether or not to use the `inline` keyword. – Lightness Races in Orbit Oct 31 '16 at 18:28
  • @LightnessRacesinOrbit I guess that's what I'm asking. What effect does defining a function inline have on that function being inlined, or conversely, what effect does not defining a function inline have on it being inlined. If the compiler decides what to inline or not, and I'm not developing a header-only library, is there *any* reason to define the function inline? – Steve Lorimer Oct 31 '16 at 18:28
  • @SteveLorimer: Then this is a duplicate of the question you linked to. – Lightness Races in Orbit Oct 31 '16 at 18:28
  • AFAIK, defining a function inline *and/or* using the `inline` keyword have nothing to do with whether or not the compiler will inline that function. – 0x5453 Oct 31 '16 at 18:28
  • @LightnessRacesinOrbit *Only the compiler makes that choice*. Does that mean that *Cheers and hth. - Alf's* comment is incorrect? – Steve Lorimer Oct 31 '16 at 18:29
  • @SteveLorimer: To be generous, we could call it "out of date". The `inline` keyword has mandatory effects on a function's linkage, but will it change GCC's mind on whether to _actually_ inline a thing? Nowadays? Quite rarely. Alf is right about one thing - _measure it_. If you try to come up with a general rule, you will fail. – Lightness Races in Orbit Oct 31 '16 at 18:29
  • @LightnessRacesinOrbit so the advice from the linked question is out of date, and defining functions inline in the header as a means to improve performance is completely pointless these days? – Steve Lorimer Oct 31 '16 at 18:30
  • 1
    @Steve: Now you're asking something else. You're making it about "in the header" versus "not in the header", to which the answer is "it depends how good your toolchain is at link-time optimisation". – Lightness Races in Orbit Oct 31 '16 at 18:31
  • @SteveLorimer From my experience, most modern compilers ignore the `inline` keyword as far as deciding whether or not to actually inline. If you want to control it on a modern compiler, you need to use a force-inline or force-no-inline directive (which varies by compiler.) Force-inline will still fail in some cases where it technically isn't possible to inline (recursion/function pointer), or where the compiler has a limitation (i.e. MSVC sometimes can't inline functions that return objects by value). – Mysticial Oct 31 '16 at 18:33
  • @LightnessRacesinOrbit well it would be in the header vs not in the header wouldn't it? That is, if it's defined inline it has to be in the header? As such, I guess that it's an implicit part of the question, and part of what I'm seeking further enlightenment about – Steve Lorimer Oct 31 '16 at 18:35
  • 1
    To answer your last bullet. It's, "If you know better than the compiler." Compilers are very good at making inlining decisions. But that doesn't mean they always do better than a well-informed human. So the usual rules of profiling apply. I'm a particularly big user of force-inline for SIMD-heavy code where the cost of a function call is very high due to the need to save and restore dozens of registers. And modern compilers are very reluctant to inline functions consisting of hundreds of instructions even when the speedup can be upwards of 20% or more. – Mysticial Oct 31 '16 at 19:04
  • @Steve: _"if it's defined inline it has to be in the header?"_ No, these are two orthogonal concepts you're discussing simultaneously :) – Lightness Races in Orbit Nov 01 '16 at 11:46

0 Answers0