CODEWITHSUNDEEP
c++cperformance
Gilad
Gilad

Reputation: 6575

can overuse in Macros hurt performance?

I have a very long code, which is being called millions of time, I have noticed that if I change all the macros into inline functions the code runs a lot faster.

Can you explain why this is? Aren't macros only a text replacement? As opposed to inline functions which can be a call to a function?

Upvotes: 5

Views: 6103

Answers (4)

cmaster - reinstate monica
cmaster - reinstate monica

Reputation: 40604

Apart from forcing inlining, macros can also be detrimental to speed if they are not carefully written not to evaluate their arguments twice. Take for example this little function-like macro and its inline function equivalent:

#define square(x) ((x)*(x))

inline long square(long x) { return x*x; }

Now, when you call them with a variable square(foo), they are equivalent. The macro vesion expands to ((foo)*(foo)), which is one multiplication just like the function if it's inlined.

However, if you call them with square(expensiveComputation(foo)), the result of the macro is, that expensiveComputation() is called twice. The inline function, in contrast, behaves like any function: its argument is evaluated once before the body of the function is executed.

Of course, you could write the macro using the gnu extension of compound statements (see http://gcc.gnu.org/onlinedocs/gcc/Statement-Exprs.html for documentation on this) to avoid double evaluation like this:

#define square(x) ({ \
    long square_temp_variable = (x); \
    square_temp_variable*square_temp_variable; \
})

But this is a lot of hassle, and it makes the code unportable. So, better stick with inline functions.

Upvotes: 6

Damon
Damon

Reputation: 70126

A macro is a text sustitution and will as such generally produce more executable code. Every time you call a macro, code is inserted (well, not necessarily, the macro could be empty... but in principle).
Inline functions, on the other hand, may work the same as macros, but they might also not be inlined at all.

In general, the inline keyword is rather a weak hint than a requirement anyway, compilers will nowadays judiciously inline functions (or will abstain from doing so) based on heuristics, mostly the number of pseudo-instructions.

Inline functions may thus cause the compiler to not inline the function at all, or inline it a couple of times and then call it non-inined in addition.
Surprisingly, not inlining may actually be faster than inlining, since it reduces overall code size and thus the number of cache and TLB misses.

Upvotes: 8

sabbahillel
sabbahillel

Reputation: 4425

This will depend on the particular macro and function call that you are using. A particular macro can actually compile to a longer set of operations than the inline function. It is often better not to use a macro for certain processes. The inline function will allow the compiler to type check and optimize the various processes. Macros will be subject to a number of errors and can actually cause various inefficiencies (such as by having to move variables in and out of storage).

In any case, since you actually see this happening in your code, you can tell that the compiler is able to optimize your inline code rather than blindly put in the text expansion.

Note that a google search 'macros vs inline' shows a number of discussions of this.

Upvotes: 7

vlad_tepesch
vlad_tepesch

Reputation: 6891

at general it is a good advise to replace function style macros by inline functions wherever this is possible.

not only you ged rit of some nasty traps a = MIN(i++, 50) for example you also gain typesafety and as already stated in some comments you avoid multiple evaluation of arguements, that may have very bad influence on performance.

Upvotes: 3

Related Questions