CODEWITHSUNDEEP
performancelanguage-agnostic
JMP
JMP

Reputation: 7834

When should I consider the performance impact of a function call?

In a recent conversation with a fellow programmer, I asserted that "if you're writing the same code more than once, it's probably a good idea to refactor that functionality such that it can be called once from each of those places."

My fellow programmer buddy instead insisted that the performance impact of making these function calls was not acceptable.

Now, I'm not looking for validation of who was right. I'm simply curious to know if there are situations or patterns where I should consider the performance impact of a function call before refactoring.

Upvotes: 3

Views: 200

Answers (7)

Catfish_Man
Catfish_Man

Reputation: 41801

You care about function call overhead the same time you care about any other overhead: when your performance profiling tool indicates that it's a problem.

Upvotes: 1

justin
justin

Reputation: 104698

for the c/c++ family:

the 'cost' of the call is not important. if it needs to be fast, you just have to make sure the compiler is able to inline it. that means that:

  • the body must be visible to the compiler

  • the body is indeed small enough to be considered an inline candidate.

  • the method does not require dynamic dispatch

there are a few ways to break this default ability. for example:

  • huge instruction count already in the callsite. even with early inlining, the compiler may pop a trivial function out of line (even though it could generate more instructions/slower execution). early inlining is the compiler's ability to inline a function early on, when it sees the call costs more than the inline.

  • recursion

the inline keyword is more or less useless in this era, regarding its original intent. however, many compilers offer a means to restore the meaning, with a compiler specific directive. using this directive (correctly) helps considerably. learning how to use it correctly takes time. if in doubt, omit the directive and leave it up to the compiler.

assuming you are using a modern compiler, there is no excuse to avoid the function, unless you're also willing to go down to assembly for this particular program.

as it stands, and if performance is crucial, you really have two choices:

1) learn to write well organized programs for speed. downside: longer compile times

2) maintain a poorly written program

i prefer 1. any day.

(yes, i have spent a lot of time writing performance critical programs)

Upvotes: 0

XIVSolutions
XIVSolutions

Reputation: 4502

My bet is that there was a time in which the performance cost of a call to an external method or function WAS something to be concerned with, in the same way that the lengths of variable names and such all needed to be evaluated with respect to performance implications.

With the monumental increases in processor speed and memory resources int he last two decades, I propose that these concerns are no longer as pertinent as they once were.

We have been able use long variable names without concern for some time, and the cost of a call to external code is probably negligible in most cases.

There might be exceptions. If you place a function call within a large loop, you may see some impact, depending upon the number of iterations.

I propose that in most cases you will find that refactoring code into discrete function calls will have a negligible impact. There might be occasions in which there IS an impact. However, proper TESTING of a refactoring will reveal this. In those minority of cases, your friend might be correct. For most of the rest of the time, I propose that your friend is clining a little to closely to practices which pre-date most modern processors and storage media.

Upvotes: 1

T.E.D.
T.E.D.

Reputation: 44804

"My fellow programmer buddy instead insisted that the performance impact of making these function calls was not acceptable."

...to which the proper answer is "Prove it."

The old saw about premature optimization applies here. Anyone who isn't familiar with it needs to be educated before they do any more harm.

IMHO, if you don't have the attitude that you'd rather spend a couple hours writing a routine that can be used for both than 10 seconds cutting and pasting code, you don't deserve to call yourself a coder.

Upvotes: 3

Kon
Kon

Reputation: 27431

You need to ask yourself several questions:

  1. Cost of time spent on optimizing code vs cost of throwing more hardware at it.
  2. How does this impact maintainability?
  3. How does going in either direction impact your deadline?
  4. Does this really beg optimization when many modern compilers will do it for you anyway? Do not try to outsmart the compiler.

And of course, which will help you sleep better at night? :)

Upvotes: 1

Jan Zyka
Jan Zyka

Reputation: 17898

Modern compilers of languages such as Java will inline certain function calls anyway. My opinion is that the design is way more important over the few instructions spent with function call. The only situation I can think about would be writing some really fine tuned code in assembler.

Upvotes: 2

Mark Ransom
Mark Ransom

Reputation: 308111

Don't even consider the effect of calling overhead if the code isn't in a loop that's being called millions of times, in an area where the user is likely to notice the difference. Once you've met those conditions, go ahead and profile to see if your worries are justified.

Upvotes: 2

Related Questions