Function call overhead (C programming)
Looking at my program ive noticed that im extensivly useing alot of functions to split the program up and im wonding if im incuring a performance hit because of the number of functions im calling from other functions. Is function overhead still a problem or does GCC and other moden compilers allevate this ?
Also does the number of file descriptors count as a program is run or does the Operating system get one back when the stream is closed ? |
In general, the compiler makes decisions about how to reduce function call overhead. You can force the issue with inline function calls, which ask the compiler to inline the function code.
You shouldn't worry about performance unless you know there is an issue. For example, have you profiled your code and found a big bottleneck? or are you running in an arm environment where resources are very limited? File descriptors are "counted" by the kernel when a file is opened or closed. COuld you tell us what you mean by "get one back"? |
"Premature optimization is the root of all evil." If the code works elegantly and understandably with all the function calls in, best to keep it that way until you know you've got a problem.
File descriptors are issued on a per-process basis. Whenever you close a file in your program, it's descriptor becomes available for use again, so as long as you close files when you're done with them you should be OK. (Unless you are expecting to read from a million different files simultaneously.) |
Ahh ok I wasent really worried that my program was slow at all considering its rather basic in its function and nasty in it's current form. Its going to be rewritten but for a passing intrest I was just curious if people really worried about it anymore with C code. As for the file descripters yes thank you and no im not opening millions of files just the same one over and over again. (this is part of the nasty part :p)
|
Quote:
Hence yes, break it down and go for those functions. |
All times are GMT -5. The time now is 07:46 PM. |