Want to protect your cyber security and still get fast solutions? Ask a secure question today.Go Premium

  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 252
  • Last Modified:

Use of Macros versus Function Calls for speed

can anyone tell me why using a macro is faster in some cases than a function call.
searching on the internet, the answer found most frequently stated that macros avoid
the "runtime overhead of a function call". Can anyone explain what runtime overhead
this refers to?
1 Solution
macros are faster in runtime because  macros are inline text replacements

see this
 if u do
#define MAX(a,b) (a>b)?a:b

compiler reads the macro and generates the following source code to be compiled further

#define MAX(a,b) (a>b)?a:b

which is faster then making a function call to the function
int max(int a, int b){
return (a>b)?a:b;

making a function call , involves lots of step .. at the runtime ..which makes it slower as compared to macro of same source code.

but if a macro is big enough ( u ca have multi line macros)
and is being used at many places in the code ..
then due to text replacement .. the source codes get quite big and hence the executable generated also gets bigger..

I hope u know , what happens when a basic function call is made at the runtime..

if u are gcc , i can tell u how u can see the preprocessed source code .. ( preprocessing means compiler parses  all the # preprocessor directives and does some of its stuff )

u can see with gcc
gcc -S file.c

( if u want to test this command i wud suggest u to make a very very small program .. with some macro uses .. and no #includes , because compiler replaces the original text of the include file at the place where u do #include )

and u'll observe that all ur macro 'calls' are replaced with appropriate source code .

while function calls will remain as they are.
The above is correct... Macros cause a text replacement at preprocess time so it is like the code is right there and at runtime doesn't even exist.  

Functions have to do a lot of things to be run, most notabley they have to allocate stack space for the parameters and locals that it has, and it has to save off where you where executing before the funtion call.  When it exits it has to deallocate that stack space resotre the program counter etc. This is what the runtime overhead refers to, the stack space and other such things that you must save off to return from the funtion.  

Also if the function is written in a way you may have to do a lot of copying to execute the function

for example

void foo(int x)

has to copy x inorder to call foo.  This can get problematic if instead of an int you pass a structure of ints that is 10kb large or something.

Anyway, these days I don't get too worked up about the runtime overhead of function calls.  Likely if you don't pass large structures by value, don't write functions with a huge amount of local variables (which may have to be used anyway without a new function)  then the cost of calling the function is trival compared to the rest of the program.  

At least in VC++ you do not see the macro expanded and it does make debugging a little trickier.

Hope that helps
What does it mean to be "Always On"?

Is your cloud always on? With an Always On cloud you won't have to worry about downtime for maintenance or software application code updates, ensuring that your bottom line isn't affected.

rubydiamondAuthor Commented:
thanks very much - both those answers explain a lot! :)

the application i'm writing has a lot of floating point maths - so i'm trying to convert all this to fixed point maths. I'm working on a processor that isn't very fast at all and so i'm thinking i should be using macros rather than function calls for these fixed point conversions and operations becuase they are used a great deal.
your decision shud also consider how much calculation do u intend to do in one 'CALL'
also if u have restrictions on memory also .. that also u shud take into consideration.. extensive use of macros may increase ur executable size ..
but i dont think u'll be having that big a program..
macros are *usually* faster than calls,
EXCEPT in modern computers, where macros may expand your code so much that it won't fit in the level-1 cache (usually 4K to 64K).  If your main loop gets that big, then the CPU will have to get its next instruction from main memory, which may take 5-10 times longer.

Yuor smarter compilers can generate in-line code for intrinsic functions, and some even will inline short functions that you write.   So #defining functions as macros isnt quite a good thing as it used to be.


Featured Post

Concerto's Cloud Advisory Services

Want to avoid the missteps to gaining all the benefits of the cloud? Learn more about the different assessment options from our Cloud Advisory team.

Tackle projects and never again get stuck behind a technical roadblock.
Join Now