Which of the following code is likely to take less time to get executed?

/*Format 0*/
main(){
    int a=3,b=5;
    printf("%d",a*b);
}



/*Format 1*/
int mult(int a,int b){
    return a*b;
}
main(){
    printf("%d",mult(3,5));
}



/*Format 2*/
inline int mult(int a,int b){
    return a*b;
}
main(){
    printf("%d",mult(3,5));
}

As of now,I understand that the compiler inserts a snippet of the function everytime it encounters a function call to mult().Then which of the above is likely to be executed fastest?(If at all there is a differnce between their execution times in the range of nanoseconds or picoseconds?

Dani AI

Generated

Short answer: the straight expression (the Format 0 style) is the simplest and will usually be fastest in an isolated snippet, but the printf in the examples overwhelms any microsecond/nanosecond differences. As noted, the inline keyword is only a hint; modern compilers make the final decision based on optimization settings and heuristics.

A few clarifications that the thread hasn't fully spelled out:

  • Compilers will constant-fold and optimize simple constant arithmetic at compile time, and with -O2/-O3 (and especially with link-time optimization) a small function call will often be inlined by the optimizer so its generated code is identical to a direct expression.
  • In debug builds inlining is typically disabled, and taking a function address or making the function too large will prevent inlining.
  • Measuring with printf is misleading: I/O dominates timing. For real measurements, remove I/O, use a high-resolution timer or hardware counters, and inspect the generated assembly to confirm what the compiler did.

Macros vs inline functions: prefer inline functions for type safety, scope, and single evaluation of arguments. Macros are text substitution and can bite with precedence and multiple evaluations (as and pointed out). Use macros only when the preprocessor is actually needed (compile-time constants, conditional compilation, or tricks not expressible in plain C).

A practical check (safe header pattern + microbenchmark skeleton):

/* header.h */
static inline int mul_inline(int x, int y) { return x * y; }

/* test.c */
#include "header.h"
volatile int sink;
int main(void) {
  for (long i = 0; i < 100000000; ++i) sink += mul_inline(3, 5);
}

Compile with optimizations and inspect assembly (example): gcc -O2 -march=native -S test.c or use objdump -d on the object to see if the call was inlined. Conclusion: prefer static inline / inline functions for small utilities; macros only when necessary, and always confirm by inspecting generated code rather than guessing.

Recommended Answers

All 8 Replies

Compilers are not required to honor the inline keyword, so the first example is guarenteed to be the fastest. The other two examples may or may not be the same timing, depending on the compiler.

If at all there is a differnce between their execution times in the range of nanoseconds or picoseconds?

Execution is measured in "waste of programmer time" intervals that increase in direct proportion to the triviality of the statement.

commented: LOL +14
commented: ha ha ha... ha +14
commented: Love it!! +14

Ah yes,the above statement being correct,which of the following is recommended ?

/*Inline function*/
inline int mult(int x,int y){
    return x*y;
}

OR

/*Macro-Preprocessor directive*/
#define mult(x,y) x*y

And why?

The first one. macros are evil creatures. The macro is wrong anyway. should be like this: #define mult(x,y)(x)*(y)

No,that worked fine. By the way,in this simple operation,precedence should not be a concern.

The reason you need the parentheses in the macro is so that you can call the macro with something like this: mult(2+5,10/2) it will look like this when expanced
2+5*10/2 = 2 + 50/2 = 2 + 25 = 27, which is not the correct answer.

Inline functions don't have the above problem.

Yeah,but here supplying only integers(not unevaluated arithmetic expressions) will help.

Yeah,but here supplying only integers(not unevaluated arithmetic expressions) will help.

Expecting someone, even yourself, to use a macro correctly is overly optimistic. The macro should be as dummy-proof as possible

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.