- Forum
- General C++ Programming
- Overhead of functions
Overhead of functions
What is the performance impact of using functions in a program to help clean up code. Aside from the benefits of being easy to read, debug and maintain, are there any performance benefits? Are there losses? If so, are they noticible with say, a 4 level nesting of functions?
I know inline functions are typically faster than regular functions, but I don't know when one should be preferred over the other, or it is best not to use a function at all.
Thanks,
Jared
I know inline functions are typically faster than regular functions, but I don't know when one should be preferred over the other, or it is best not to use a function at all.
Thanks,
Jared
You will only feel the impact of using functions when running a very tight loop. For example, if you need to run something 10k-100k times per second. Otherwise, it's practically unnoticeable.
Four calls is nothing.
You're in luck. C++ compilers (all of them), understand
However, some compilers provide keywords to force inlineness. Of course none of them are standard.
Four calls is nothing.
You're in luck. C++ compilers (all of them), understand
inline as merely a suggestion, rather than an order.However, some compilers provide keywords to force inlineness. Of course none of them are standard.
Answer looks good but i would like to add few lines here,
Regarding functions, yes obviously it gives you some overhead but you need to carefully identify the piece of code or say to say operations which you need to use again and again in your entire code, that part should be put into separate function, so sometimes (when working with big projects or modules) its absolutely necessary to create functions you just simply can't avoid it, but as i said, to carefully identify the piece of code is important,
and regarding inline functions, yes they are faster because, they are bind with the call at compile time, inline functions have their own rules, for e.g. you can't declare loop and some other things in inline functions... so when you have piece of code which does not include such things (like loop and all) you can use inline functions. rather than normal functions..
Regarding functions, yes obviously it gives you some overhead but you need to carefully identify the piece of code or say to say operations which you need to use again and again in your entire code, that part should be put into separate function, so sometimes (when working with big projects or modules) its absolutely necessary to create functions you just simply can't avoid it, but as i said, to carefully identify the piece of code is important,
and regarding inline functions, yes they are faster because, they are bind with the call at compile time, inline functions have their own rules, for e.g. you can't declare loop and some other things in inline functions... so when you have piece of code which does not include such things (like loop and all) you can use inline functions. rather than normal functions..
Inlined functions place copies of the code where used. That will cause the program to get larger. The larger code can cause a page fault at runtime that would not otherwise be necessary, which wipes out any percieved performance benefits.
| you can't declare loop and some other things in inline functions |
I would understand that you can't use recursion with an inline function, but no loops? WTF?
kbw: But paging will only occur if the program gets large enough. It is also impossible to know when it will happen or how often, because it depends on the physical distribution of code. For example, you may inline a function that appears in many tight loops, and this causes paging every five minutes. Does that nullifies the performance gain? What if it happens just before an IO operation? It wouldn't make much of a difference.
Besides, the compiler is then one who ultimately inline the function or not at every call to it. Chances are, not every call will get inlined.
What everyone is explaining can be summarized as:
Only use inline functions for very small functions. That is where the benefit may be noticed, particularly when the function is called often. Access methods are ideal candidates.
With larger functions, the bottleneck in performance would not likely be the function call, but rather the body of the function.
Only use inline functions for very small functions. That is where the benefit may be noticed, particularly when the function is called often. Access methods are ideal candidates.
With larger functions, the bottleneck in performance would not likely be the function call, but rather the body of the function.
+1 seymore.
I think what you have to consider, is that when you start coding you end up writing a lot of small apps/pieces of code. These pieces of code are usually less than 2k lines. So you don't really need more than 1-5 functions.
Once you start working on apps that exceed 10,000 lines or even 1million lines you end up working with thousands of functions. You just need that level of maintainability on your code.
I think what you have to consider, is that when you start coding you end up writing a lot of small apps/pieces of code. These pieces of code are usually less than 2k lines. So you don't really need more than 1-5 functions.
Once you start working on apps that exceed 10,000 lines or even 1million lines you end up working with thousands of functions. You just need that level of maintainability on your code.
Im at 6000 lines and all I have in place is the structure of the code....havn't even started writing in the actual calculations. I've decided to replace sections of code with functions if for no other reason then because it makes the source file faster to scroll through (the indentation levels are starting to get a bit extreme too).
Last edited on
I am, but I still need the main function to handle a lot. This program handles more data by many orders of magnitude than anything Ive ever written before, and I want to have it multi-processed (now) and multi-threaded (eventually). Im sure you know there can be a lot of code to set that up when you are working with large data sets that also have to be logged.
If your main function is large, you should consider braking the functionality off into more classes.
In a project with 20-25k LOC the main function is 75 lines. Most of this is the wrapping and handling of exceptions at the highest level. Even parsing the command line is given to another object to handle.
In my case, the RuntimeController will parse the command line arguments, send the values to the required controller and spawn the execution path required. Then it passes controller to another class that is responsible for calling the individual units of work.
In a project with 20-25k LOC the main function is 75 lines. Most of this is the wrapping and handling of exceptions at the highest level. Even parsing the command line is given to another object to handle.
In my case, the RuntimeController will parse the command line arguments, send the values to the required controller and spawn the execution path required. Then it passes controller to another class that is responsible for calling the individual units of work.
For now it is easier to leave everything in the main function. Once I get the method working right, I will split it up more and then finish it. Right now I don't have all of the parameters in the code, but rather just enough to determine if the structure functions properly.
Topic archived. No new replies allowed.