21

Often, people speak of the calling of functions producing a certain amount of overhead, or an inescapable set of additional concerns and circumstances, in a program. Can this be better explained and compared to a similar program without the function call?

sg7
  • 6,108
  • 2
  • 32
  • 40
Kamuela Franco
  • 686
  • 1
  • 5
  • 16
  • 1
    possible duplicate of [What happens in assembly language when you call a method/function?](http://stackoverflow.com/questions/1585137/what-happens-in-assembly-language-when-you-call-a-method-function) – Michael Petch Aug 03 '15 at 04:17
  • What are _"these routines"_ you refer to? – Jens Aug 03 '15 at 04:23
  • 5
    It's not always possible to inline. Recursive functions, virtual functions, and function pointers are examples. (sometimes they still can be inlined, but not in the general case) – Mysticial Aug 03 '15 at 04:23
  • It's also important to notice that, input arguments are sometimes constant values (hard coded parameters, such as a loop count, known at compile time but different depending on call site). `inline`ing such functions exposes those constant values to the compiler, which enables more aggressive optimization. – user3528438 Aug 03 '15 at 12:39

4 Answers4

10

It depends on your compiler settings and the way it optimizes code. Some functions are inlined. Others are not. It usually depends on whether you're optimizing for size or for speed.

Generally, calling function causes delay for two reasons:

  • The program needs to hook to some random location in memory where your function code starts. To do this, it needs to save the current cursor position into a stack so it knows where to return. This process consumes more than one CPU cycle.

  • Depending on your CPU architecture, there may be a pipeline, which fetches the next few instruction from memory into the CPU cache in parallel with your current instruction execution. This is to speed up execution speed. When you call a function, the cursor hooks to a completely different address and all the cached instructions are flushed from the pipeline. This causes further delays.

Evan Carroll
  • 78,363
  • 46
  • 261
  • 468
Francois Zard
  • 350
  • 2
  • 13
  • 7
    1) and 2) are not the norm. Modern architectures are pretty good predicting code execution. Also note that a function call is _always_ predictable because you know where execution goes, and therefore you can prefetch code and fill the pipeline. No delays there. – Jens Aug 03 '15 at 04:29
  • They are for the x86 arch AFAIK – Francois Zard Aug 03 '15 at 04:50
  • Nope, x86 `CALL` is about one cycle these days. – Jens Aug 03 '15 at 11:12
  • Calling convention matters too. Callee and caller clobbered registers need to be saved and restored. When you add in stack adjustment and frame pointers, it is often cheaper to inline small functions even when optimizing for size. – technosaurus Mar 09 '18 at 23:10
8

Also see here and here for a discussion on when inlining would make sense.

  • Inlining

    In general, you can only suggest to the compiler to inline a function, but the compiler might decide otherwise. Visual Studio offers its own forceinline keyword though. Some functions can not be inlined, e.g. when they are recursive or when the target function can not be determined at compile time (calls through function tables, virtual function calls in C++).

    I suggest you trust the compiler whether or not a function should be inlined. If you truly want to inline your code, consider using a macro instead.

  • Overhead

    Memory overhead is at a minimum when you use functions because you do not duplicate code; inlined code is duplicated into the call site. Performance overhead these days is negligible because modern architectures are really good predicting and calling with about 1-2 cycle overhead only.

Evan Carroll
  • 78,363
  • 46
  • 261
  • 468
Jens
  • 8,423
  • 9
  • 58
  • 78
2

The functions can be inlined, but the norm (mostly) is functions are at a particular address, and values passed to the function are put on the stack and the result is then put on the stack and returned.

TryinHard
  • 4,078
  • 3
  • 28
  • 54
Keith Nicholas
  • 43,549
  • 15
  • 93
  • 156
  • Almost all architectures use register based calling conventions when code is optimized to keep data as close to the execution as possible. Return values are always returned in a register. – Jens Aug 03 '15 at 04:31
  • some are, but I consider that an optimization. I do a lot of embedded programming, and a lot of those have very little in the way of register space to do that. – Keith Nicholas Aug 03 '15 at 04:35
  • @Jens x86 still uses stack-based calling convention and most other microcontrollers still use the stack to pass parameters due to the lack of registers. Return values are only passed through register if it's small enough to fit in 1 or 2 registers, otherwise it'll be returned via stack – phuclv Aug 03 '15 at 04:41
2

Functions certainly can be inlined, if some conditions are met, but they are definitely not always inlined. Most often, calling a function produces a genuine non-inlined function call. A function call has some additional expenses attached to it, such as

  • Preparing parameters for the function in accordance with the function's calling convention
  • Receiving the return value of the function
  • Function prologue and epilogue code, responsible for local memory management, parameter memory management and register value preservation
  • Function can clobber some CPU registers, thus disrupting their usage in the calling code and thus impeding optimizations
  • Less CPU-cache-friendly and virtual-memory-friendly behavior of code executed in non-linear fashion

All this will produce overhead likely would no exist if the function body was embedded inline into the calling code.

AnT stands with Russia
  • 312,472
  • 42
  • 525
  • 765