inline functions

[nitin1]

If i use macros as functions , then at compilation time , that macros will me be written as function code. so is it better than inline functions and then why don't we use macro always to write the functions as it will speed up our execution. so writing macro may increase time at compilation time, but shouldn't it help at execution time as we are saving our overheads in the funtionc calling. I know i am wrong some-where, so can you please correct me ? thanks.

[Adak]

Macros are pure substitution, and are handled by the pre-processor, before anything is compiled. Macros will be handled just as if you had entered the substituted code, without the macro. There is no run-time gain.

They are a tool that can help if you sensibly, or hurt if over-used.

[Ancient Dragon]

inline functions, the compiler can choose to make them inline as if they had been macros or to just make them regular functions. inline functions as well as functions written as macros has the potential to bloat the compiled program, making it a lot larger than if the function had been written as normal functions. With macros the compiler has no options but to duplicate the code every time it is called. But if you use inline functions the compiler can elect to make them normal functions in order to reduce program size.

Here are a few guidelines I follow:

1. never write functions as macros, IMO that is just bad programming style.
2. One or two statement functions should be written as inline functions.
3. Any functions larger than two statements should be normal functions.

[deceptikon]

so writing macro may increase time at compilation time, but shouldn't it help at execution time as we are saving our overheads in the funtionc calling.

Close. Inlined code through either an inline function or function-like macro can reduce execution performance if the increased object code size results in excessive cache misses or thrashing.

These days the overhead of a function call is negligible, so it shouldn't be your reason for introducing inline hints; there's more to that particular decision than call instructions and loading/unloading stack frames.

[nitin1]

so, inline functions are always good to use in our code ? and why should i prefer macro over the inline and why should i prefer inline over macro ? Can you make it clear little bit ? but, if program length increases, then why it should increase the execution time ? I mean why file size matters as code which is executed is same in both the cases. (when macro is used and second when macro is not used).thanks.

[sepp2k]

You should never prefer macros over inline functions. The only case where you'd use macros would be if you're writing for a compiler that does not support inline functions¹ or you're using macros as something other than a poor man's inline functions² - though even then you should think about whether you couldn't implement the desired functionality in pure C before you decide to use macros.

¹ Standard C did not support inline functions until the 99 standard though some compilers supported them as an extension before then.

² For example gtk/gobject uses macros to implement its object system. QT (though that's C++, not C) uses macros (in combination with its moc preprocessor) to implement its signals and slots. Its foreach loop is also implemented as a macro.

[sepp2k]

One thing that should be noted is that the compiler can inline functions even when they're not declared as inline when it thinks doing so will be appropriate. So for the most part the keyword is unnecessary.

Another thing to keep in mind is that, without link-time optimization, the compiler won't inline a function if the function's source code is not available in the current compilation unit (i.e. if the function definition lives in a different .c file than the call). So if you want a function to be inlined across compilation units, you should put the function definition in the header as either static or extern inline.

[nitin1]

"So if you want a function to be inlined across compilation units, you should put the function definition in the header as either static or extern inline."

Please explain this line little bit more. thanks

Secondly, can we relate the disadvantage of long program size with number of page faults ? how can we do that ? thanks if you can help me.

[nitin1]

@James sir,
Can you please throw light on this statement ?

"the increased object code size results in excessive cache misses or thrashing.". Thanks. This was the point which i want to know about.

[deceptikon]

One thing that should be noted is that the compiler can inline functions even when they're not declared as inline when it thinks doing so will be appropriate.

Also, inline is nothing more than a hint. The compiler is free to ignore it. That's one benefit (in a sea of downsides) to function-like macros: they're guaranteed inlining.

so, inline functions are always good to use in our code ?

I'd say the opposite. Inline functions are to be avoided until you can provide solid proof through a profiler that you've both got a bottleneck and that inline functions fix it. Otherwise they're not worth the hassle.

Can you please throw light on this statement ?

"the increased object code size results in excessive cache misses or thrashing."

Code gets loaded into memory in the form of instructions. You want your executing code to be loaded into a single cache line so that it's not swapped into RAM (slow) or even paged into virtual memory (hideously slow) an excessive number of times before completion.

When a function gets inlined, the calls are replaced with the whole of the function body rather than simply referencing the body through a call instruction, which can potentially increase your instruction size by orders of magnitude. So while you might save yourself the overhead of loading stack frames and executing call instructions, the overhead of duplicating code could cause you to cross those thresholds and be measurably slower than the overhead you're trying to avoid.

Inline functions are what I'd call an expert's feature. They're great when used well, but vary between useless and significantly detrimental when used poorly. And the first step in using them well is measure, measure measure.

[sepp2k]

"So if you want a function to be inlined across compilation units, you should put the function definition in the header as either static or extern inline."

Please explain this line little bit more.

If you structure your code like this, fun will likely not be inlined:

// fun.c

int fun(int x) {
    return x;
}

// fun.h

int fun(int);

// main.c

#include "fun.h"

int main(int argc, char **argv) {
    fun(42);
    return 0;
}

But if I do it like this:

// fun.h

static int fun(int) {
    return x;
}

// main.c

#include "fun.h"

int main(int argc, char **argv) {
    fun(42);
    return 0;
}

Or like this:

// fun.c

int fun(int x) {
    return x;
}

// fun.h

inline int fun(int) {
    return x;
}

// main.c

#include "fun.h"

int main(int argc, char **argv) {
    fun(42);
    return 0;
}

Then it probably will be.

Note that in my previous post I said "extern inline", but it should just be "inline" in C99 - confusingly the meanings of "extern inline" vs. "inline" are switched around in GNU C89 (i.e. C89 plus GNU extensions, which is the default language of gcc) vs. C99. For more information see this SO question.