What are the benefits of inline functions?

Question

What is the advantages/disadvantages of using inline functions in C++? I see that it only increases performance for the code that the compiler outputs, but with today's optimized compilers, fast CPUs, huge memory etc. (not like in the 1980< where memory was scarce and everything had to fit in 100KB of memory) what advantages do they really have today?

Ferrite

This is one of those questions where common knowledge is wrong. Everybody has answered with the standard Comp Sci answer. (Inlining saves function call costs but increases code size). Rubbish. It provides a simple mechanism for the compiler to apply more OPTIMIZATIONS. – Polity

This is one of those answers posing as comments. If you don't like any of the answers that were posted, post your own answer and see how it goes. – Motivity

The basis of this question is flawed. C++ inline functions have little to do with compilers inlining during compilation. It is unfortunate that inline is a c++ keyword and that inlining is a compiler optimization technique. See this question "when should I write the keyword inline for a function/method" for the correct answer. – Aether

@JoseVega Your link got mangled - the current link is exforsys.com/tutorials/c-plus-plus/inline-functions.html – Advancement

Answer 1

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

Sororate

As I suspected inlining makes no difference to the above. Compiled with gcc 4.01. Version 1 forced to use inlining: 48.318u 1.042s 5:51.39 99.4% 0+0k 0+0io 0pf+0w Version 2 forced no inlining 348.311u 1.019s 5:52.31 99.1% 0+0k 0+0io 0pf+0w This is a good example were common knowledge is wrong. – Polity

while the call itself indeed matters, that's only the minor gain you get by using inline. The major gain is, that the compiler now see where pointers don't alias each other, where variables of the caller end up in the callee and so on. Thus, the following optimization is what matters more. – Bridgman

It probably doesn't make a difference in this snippet since the result of the function is never used nor does the function have side effects. We see a measurable performance gain in inlining in image processing. – Connotative

The reason for no difference could be that the compiler might inline on its own accord; or that the code is small so there are no code prefetch issues. – Lentha

@Lentha The compiler may have even optimized out the entire loop because of that. – Steamroller

@LokiAstari How confident are you that you actually forced gcc to inline the function? Read the disassembly? Turns out that this is a function that gcc really, really doesn't want to inline. Even if you give it the inline tag, it will not be inlined on -O0. Whereas, at an optimization level of 0, giving one function the always_inline attribute and the other the noinline attribute and forcing the code to actually run (ie, not optimizing the functions out of existence), I got a solid 17% speedup while inlining. God, I wish comments could be downvoted so the community could correct your error. – Eckblad

@Eckblad You miss the point (see my comment above). By forcing the compiler to do something you are not seeing what actually happens. The point is that there is no action here. So yes I wish we could vote comments down. Yours is a prime example. You will see that my times shows that the inlined version is an order of magnitude faster. BUT this is not because of inline. Its because inlining allowed other optimizations that basically remove the loop. – Polity

Answer 2

Advantages

• By inlining your code where it is needed, your program will spend less time in the function call and return parts. It is supposed to make your code go faster, even as it goes larger (see below). Inlining trivial accessors could be an example of effective inlining.
• By marking it as inline, you can put a function definition in a header file (i.e. it can be included in multiple compilation unit, without the linker complaining)

Disadvantages

• It can make your code larger (i.e. if you use inline for non-trivial functions). As such, it could provoke paging and defeat optimizations from the compiler.
• It slightly breaks your encapsulation because it exposes the internal of your object processing (but then, every "private" member would, too). This means you must not use inlining in a PImpl pattern.
• It slightly breaks your encapsulation 2: C++ inlining is resolved at compile time. Which means that should you change the code of the inlined function, you would need to recompile all the code using it to be sure it will be updated (for the same reason, I avoid default values for function parameters)
• When used in a header, it makes your header file larger, and thus, will dilute interesting informations (like the list of a class methods) with code the user don't care about (this is the reason that I declare inlined functions inside a class, but will define it in an header after the class body, and never inside the class body).

Inlining Magic

• The compiler may or may not inline the functions you marked as inline; it may also decide to inline functions not marked as inline at compilation or linking time.
• Inline works like a copy/paste controlled by the compiler, which is quite different from a pre-processor macro: The macro will be forcibly inlined, will pollute all the namespaces and code, won't be easily debuggable, and will be done even if the compiler would have ruled it as inefficient.
• Every method of a class defined inside the body of the class itself is considered as "inlined" (even if the compiler can still decide to not inline it
• Virtual methods are not supposed to be inlinable. Still, sometimes, when the compiler can know for sure the type of the object (i.e. the object was declared and constructed inside the same function body), even a virtual function will be inlined because the compiler knows exactly the type of the object.
• Template methods/functions are not always inlined (their presence in an header will not make them automatically inline).
• The next step after "inline" is template metaprograming . I.e. By "inlining" your code at compile time, sometimes, the compiler can deduce the final result of a function... So a complex algorithm can sometimes be reduced to a kind of return 42 ; statement. This is for me extreme inlining. It happens rarely in real life, it makes compilation time longer, will not bloat your code, and will make your code faster. But like the grail, don't try to apply it everywhere because most processing cannot be resolved this way... Still, this is cool anyway...
  :-p

Altruistic

you said It slightly breaks your encapsulation. Will you please explain it using an example? – Untie

@PravasiMeet : It's C++. Let's say you deliver a DLL/shared library to a client, who compiles against it. The inline function foo, using member variable X and doing work Y will get inlined in the client's code. Let's say to need to deliver an updated version of your DLL where you changed the member variable to Z, and add a work YY in addition to work Y. The client just copies the DLL into their project, and BOOM, because the code of foo in their binary is not the updated code you wrote... Despite the client not having legal access to your private code, inlining makes it quite "public". – Altruistic

@Altruistic Regarding your second to last bullet point, can you give an example of when a function template is not inline? I thought they were always inline, though I don’t have a reference handy now (a simple test seems to confirm it though). – Pinnatifid

@KonradRudolph In n4594 I see: 3.2/6: There can be more than one definition of [..] inline function with external linkage [..] non-static function template. At 5.1.5/6 For a generic lambda, the closure type has a public inline function call operator member template. And at 7.1.2/2: the use of inline keyword is to declare an inline function where it is a suggestion to inline the function body at point of call. So, I conclude that even if they can behave the same, inline functions and function templates are still separate, orthogonal notions that can be mixed (ie inline function template) – Altruistic

encapsulation is broken? How so? encapsulation is for the guy(s) programming, not for the actual objects in memory. at that point no one cares. Even if you distribute a library, the compiler may choose to inline or not to do so on it's own. so in the end when you get a new lib, you just have to recompile everything that uses the functions and objects from that library. – Suspicious

Answer 3

In archaic C and C++, inline is like register: a suggestion (nothing more than a suggestion) to the compiler about a possible optimization.

In modern C++, inline tells the linker that, if multiple definitions (not declarations) are found in different translation units, they are all the same, and the linker can freely keep one and discard all the other ones.

inline is mandatory if a function (no matter how complex or "linear") is defined in a header file, to allow multiple sources to include it without getting a "multiple definition" error by the linker.

Member functions defined inside a class are "inline" by default, as are template functions (in contrast to global functions).

//fileA.h
inline void afunc()
{ std::cout << "this is afunc" << std::endl; }

//file1.cpp
#include "fileA.h"
void acall()
{ afunc(); }

//main.cpp
#include "fileA.h"
void acall();

int main()
{ 
   afunc(); 
   acall();
}

//output
this is afunc
this is afunc

Note the inclusion of fileA.h into two .cpp files, resulting in two instances of afunc(). The linker will discard one of them. If no inline is specified, the linker will complain.

Vareck

Answer 4

Inlining is a suggestion to the compiler which it is free to ignore. It's ideal for small bits of code.

If your function is inlined, it's basically inserted in the code where the function call is made to it, rather than actually calling a separate function. This can assist with speed as you don't have to do the actual call.

It also assists CPUs with pipelining as they don't have to reload the pipeline with new instructions caused by a call.

The only disadvantage is possible increased binary size but, as long as the functions are small, this won't matter too much.

I tend to leave these sorts of decisions to the compilers nowadays (well, the smart ones anyway). The people who wrote them tend to have far more detailed knowledge of the underlying architectures.

Fara

More importantly, optimizing the function body into the body of the caller allows constant-propagation and other optimizations. The "reload the pipeline" is usually an over-statement: unconditional direct branches tend to be well predicted, although a taken branch isn't free even if predicted correctly. But setup of args, and having to use call-preserved registers for things that must survive across a non-inlined call, tend to be more expensive. – Oceania

Leaving it to the compiler works well if you enable LTO (link-time optimization, like gcc -flto -O3), to allow inlining across C / C++ source files, without having to put functions in .h headers. Otherwise it can only work within one compilation unit. – Oceania

Answer 5

Inline function is the optimization technique used by the compilers. One can simply prepend inline keyword to function prototype to make a function inline. Inline function instruct compiler to insert complete body of the function wherever that function got used in code.

Advantages :-

1. It does not require function calling overhead.

2. It also save overhead of variables push/pop on the stack, while function calling.

3. It also save overhead of return call from a function.

4. It increases locality of reference by utilizing instruction cache.

5. After in-lining compiler can also apply intra-procedural optimization if specified. This is the most important one, in this way compiler can now focus on dead code elimination, can give more stress on branch prediction, induction variable elimination etc..

To check more about it one can follow this link http://tajendrasengar.blogspot.com/2010/03/what-is-inline-function-in-cc.html

Intermingle

1) It's a suggestion, not an instruction 2) It can cause more cache misses because of the increase in code size if a commonly used function is inlined a lot – Lucrative

Is the link at the end your personal blog? If it is you should declare it as such, otherwise it looks like spam. – Lucrative

Answer 6

I'd like to add that inline functions are crucial when you are building shared library. Without marking function inline, it will be exported into the library in the binary form. It will be also present in the symbols table, if exported. On the other side, inlined functions are not exported, neither to the library binaries nor to the symbols table.

It may be critical when library is intended to be loaded at runtime. It may also hit binary-compatible-aware libraries. In such cases don't use inline.

Sommer

@Johnsyweb: read my answer carefully. What you have said is true, when you are building an executable. But compiler can not simply ignore inline when building a shared library! – Sommer

static functions, or ELF __attribute__((visibility("hidden"))), are also not exported in the shared library. – Oceania

Answer 7

inline allows you to place a function definition in a header file and #include that header file in multiple source files without violating the one definition rule.

Nelidanelie

For the record, so does static, and static predates inline and is more directly defined to mean "this is not visible outside of this translation unit". – Averett

@mtraceur: True, but static makes a separate copy of the machine code for each compilation unit if the compiler chooses not to inline it at every call site in that compilation unit. With inline, those duplicate definitions gets merged by the linker. So inline is much better for functions that might not get inlined. (Smaller code footprint). – Oceania

Hmm...yes, though that difference seems easy to optimize out, so much so that I think it vanishes in practice soon enough (if you're doing whole-program optimization without throwing out information between steps, it's trivial) (if you do something like having the compiler generate the to-be-linked object file with a symbol name for that function's machine code and some annotation for that symbol telling the linker that it was inline at source level, just a little more annotation+logic would let you do it for static functions too). – Averett

I guess the big challenge for optimizing static the same as inline in this regard, and what inline really adds semantically, is that a static function with the same name is allowed to have a different definition between translation units. So if you have two linked objects with inline (but not static) function named foo, then as I understand it, the linker is allowed to just assume that they have the same definition... whereas with static (and no inline) the linker can't assume they're the same and must also compare the machine code or some additional metadata. – Averett

I would expect future compilers+linkers, and maybe even already modern ones that do link-time/whole-program optimization, to be capable of optimizations like identifying when two pieces of machine code (even without symbol names or special metadata) are identical and could be optimized by deduplicating. Optimizations always march on, and tend to sweep up any code whose semantics are conducive to such optimizations - static always had great semantics to enable all these optimizations. But yes, inline's semantics do help make some of these optimizations simpler to implement. – Averett

@PeterCordes Oh, when a function is marked inline without static, it is still extern and the compiler is forced to generate a non-inlined copy of it for possible linking (unless it can somehow prove or be told that it won't be linked). Combining static with inline fixes that, but then I'm pretty sure the function is allowed to have a different definition between translation units, so the linker can't simply assume they're the same anymore, and so we're back to the same exact optimization properties as just static without inline. – Averett

Well, to be pedantic, inline with neither static nor extern is not extern, but it does have "external linkage" - and that inline definition of the function does not need to be generated non-inlined, but some external definition of that function must occur in another translation unit, and that external definition must be generated (and I said earlier that lets the linker assume they're the same, but actually the language doesn't guarantee the inline definition will be used instead of the external one, so the linker is free to delete any non-inlined copies besides the external one.) – Averett

@mtraceur: Yes, without static, C++ inline forces generation of a stand-alone definition (unlike C where you need to instantiate the function in exactly one .c). Discarding those duplicate definitions can be done just by matching the name with C++ inline, as you say, and hopefully dropping an un-referenced definition entirely, but that's still just matching symbol names. With static inline, you need identical-code-folding optimization to realize that two separate functions (of the same name in separate compilation units) have the same machine code. ... – Oceania

... So yeah that probably requires gcc -flto, and unfortunately not all projects build that way. (When I've looked at Linux distro packages in the past, they often don't.) And you need a toolchain willing to give those potentially-distinct functions the same address. I guess it's possible that linkers would support duplicate function merging like they do for strings placed in a special section, but they'd need special support for that. A relative call or jmp tailcall to a stand-alone definition in some .o might not have a relocation entry, so removing it would break things. – Oceania

@mtraceur: Anyway, fair point that tools might be more clever than I guessed; would be interesting to check on what the current behaviour is for a couple mainstream platforms like Linux GCC / Binutils, MacOS clang etc., and MSVC. And maybe some embedded targets if they don't use use GCC/Binutils with ELF object files. But regardless, dead code (unused copies of a function) sitting around in the .text section is less bad than multiple non-inline copies actually getting called, for I-cache footprint (although not iTLB if other code in the same page is hot), and BPU (same branch at diff addrs) – Oceania

@PeterCordes re: "(unlike C where you need to instantiate the function in exactly one .c)" - yeah, that words it better! That's what I was trying to get at with "some external definition of that function must occur in another translation unit" (also in retrospect I would say "in a translation unit", not "in another"). Although I probably would say "externalize" or "make external" rather than "instantiate" - "instantiate" feels like a C++ concept, like with templates, while the relevant semantics/concepts in C are more about external visibility than whether or not an instance is created. – Averett

I'm also guilty of focusing on C, since that's what I think about a lot more than C++, so I kinda got my wires crossed between the two of them. But as far as my point goes the C and C++ versions are more same than different: in both cases we end up with a non-inlined definition somewhere in the generated code object, unless something is smart enough to notice it is unused and delete it. – Averett

@mtraceur: godbolt.org/z/Perfeez4T shows that GCC doesn't emit a stand-alone definition of the function if it chooses to inline it at every call-site, in both C and C++ mode. C++ inline also guarantees that a full definition will be visible in every compilation unit that uses it, IIRC. So that actually works better than C, with common uses not resulting in any stand-alone definitions to be discarded at link time. (Functions that are actually small and do get inlined, and without their addresses being taken, compiled with optimization enabled.) godbolt.org/z/Th8sbqrMM is -O0 – Oceania

@PeterCordes Notably, replacing inline with static in both of those godbolt examples produces the same result, which I'm more interested in since that's the main point I wanted to make with these comments - that in practice static almost always ends up being just as good as inline. – Averett

(Also, I'm not sure if the godbolt examples, which are generating code for a single translation unit with purely inline (without either extern nor static) functions, are fully representative of what the compiler normally has to do when generating a whole program. I know that even in C, those examples you gave don't generate an external definition, but we would be close to or hitting undefined behavior unless something else did, because we have only an inline definition and no external definition - but I don't yet know C++ standard enough to either agree or disagree with your conclusion.) – Averett

@mtraceur: Yes, the C version is not guaranteed to work as a complete program; the compiler could emit a call to it but wouldn't emit a definition. The point of that experiment was just to check whether C++ ended up actually emitting a stand-alone definition in every compilation unit. No, only in debug builds (when build time is most precious. Hrm...) Interestingly, static inline in C++ gets GCC -O0 to reserve less stack space, not aligning the stack by 16 before a call because it still does IPA (inter-procedural analysis) to know that the callee doesn't care about alignment. – Oceania

Answer 8

During optimization many compilers will inline functions even if you didn't mark them. You generally only need to mark functions as inline if you know something the compiler doesn't, as it can usually make the correct decision itself.

Drumstick

Many compilers also won't do this, MSVC for example will not do this unless you tell it to – Yard

@Yard I'd argue that if you didn't tell your compiler to inline functions if it would be more efficient (which in my experience for many compilers is implied by just tell ing the compiler to optimize the code) then you didn't really need or want inlined functions enough for the absence of inline in the source to be a big deal. And if a basic "optimize this well" option doesn't tell the compiler to inline functions where best, it's just not a good compiler (by modern standards anyway). – Averett

Answer 9

It is not all about performance. Both C++ and C are used for embedded programming, sitting on top of hardware. If you would, for example, write an interrupt handler, you need to make sure that the code can be executed at once, without additional registers and/or memory pages being being swapped. That is when inline comes in handy. Good compilers do some "inlining" themselves when speed is needed, but "inline" compels them.

Brachycephalic

Answer 10

Generally speaking, these days with any modern compiler worrying about inlining anything is pretty much a waste of time. The compiler should actually optimize all of these considerations for you through its own analysis of the code and your specification of the optimization flags passed to the compiler. If you care about speed, tell the compiler to optimize for speed. If you care about space, tell the compiler to optimize for space. As another answer alluded to, a decent compiler will even inline automatically if it really makes sense.

Also, as others have stated, using inline does not guarantee inline of anything. If you want to guarantee it, you will have to define a macro instead of an inline function to do it.

When to inline and/or define a macro to force inclusion? - Only when you have a demonstrated and necessary proven increase in speed for a critical section of code that is known to have an affect on the overall performance of the application.

Manilla

…If you care about space, tell the compiler to optimize for space -- telling the compiler to optimize for speed can result in smaller binaries with C++ and C. similarly, telling the compiler to optimize for space can result in faster execution. iow, these features don't always work as advertised. humans have the ability to understand some aspects of their their program better than a compiler's generalized interpretations (which must also remain usably fast). human intervention doesn't have to be a bad thing. – Dasya

You need to enable link-time optimization (like gcc -O3 -flto) if you want the compiler to be able to inline small functions across .cpp files, not just within one compilation unit. Otherwise you do need to put small hot functions in .h files (like trivial accessors), and therefore use inline. – Oceania

Answer 11

Why not make all functions inline by default? Because it's an engineering trade off. There are at least two types of "optimization": speeding up the program and reducing the size (memory footprint) of the program. Inlining generally speeds things up. It gets rid of the function call overhead, avoiding pushing then pulling parameters from the stack. However, it also makes the memory footprint of the program bigger, because every function call must now be replaced with the full code of the function. To make things even more complicated, remember that the CPU stores frequently used chunks of memory in a cache on the CPU for ultra-rapid access. If you make the program's memory image big enough, your program won't be able to use the cache efficiently, and in the worst case inlining could actually slow your program down. To some extent the compiler can calculate what the trade offs are, and may be able to make better decisions than you can, just looking at the source code.

Metalline

Answer 12

Fell into the same trouble with inlining functions into so libraries. It seems that inlined functions are not compiled into the library. as a result the linker puts out a "undefined reference" error, if a executable wants to use the inlined function of the library. (happened to me compiling Qt source with gcc 4.5.

Exedra

Answer 13

Our computer science professor urged us to never use inline in a c++ program. When asked why, he kindly explained to us that modern compilers should detect when to use inline automatically.

So yes, the inline can be an optimization technique to be used wherever possible, but apparently this is something that is already done for you whenever it's possible to inline a function anyways.

Wardrobe

Your professor is unfortunately completely wrong. inline in C++ has two very distinct meanings — only one of those is related to optimisation, and your professor is correct with regards to that. However, the second meaning of inline is often necessary to satisfy the One Definition Rule. – Pinnatifid

Answer 14

Conclusion from another discussion here:

Are there any drawbacks with inline functions?

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

Allophane

Would be true if the inline was a command and not a hint to the compiler. Compiler actually decides what to inline. – Polity

@LokiAstari I know that inline is request to compiler. My argument is If its hint to the compiler we should leave it to the compiler to decide what is best. Why to use inline any way even if you use inline it's still the compiler who will take final decision. I aslo wonder my Microsoft have introduced _forceinline. – Anorexia

@krish_oza: My comment here. Is about this answer. The answer here is completely wrong. Because the compiler disregards the inline keyword for determining whether or not to inline code all the points made above are wrong. They would be true if the compiler used the keyword for inlining (it is only used for determining marking multiple definitions for linking purposes). – Polity

A return statement is only an obstacle to manually copy/pasting the function body into another function! Not for the compiler inlining. The link supporting to weird claims is dead. A function returning a value must have a return statement in C++; if execution reaches the end of a function without a return, that's undefined behaviour. So the only way to call a non-void function without a return statement would be if the function actually doesn't return, e.g. calling a noreturn function. Some of the other sections on this answer are generally true. – Oceania