Compiler Performance – When Do Function Call Costs Matter?

You write a program to solve a problem. That problem is accompanied by a specific set of requirements for solving it. If those requirements are met, the problem is solved and the objective is achieved.

That's it.

Now, the reason that best practices are observed is because some requirements have to do with maintainability, testability, performance guarantees and so forth. Consequently, you have those pesky folks like me who require things like proper coding style. It doesn't take that much more effort to cross your T's and dot your I's, and it is a gesture of respect to those who have to read your code later and figure out what it does.

For large systems, this kind of restraint and discipline is essential, because you have to play nice with others to get it all to work, and you have to minimize technical debt so that the project doesn't collapse under its own weight.

At the opposite end of the spectrum are those one-off utilities that you write to solve a specific problem right now, utilities that you'll never use again. In those cases, style and best practices are completely irrelevant; you hack the thing together, run it, and get on with the next thing.

So, as with so many things in software development, it depends.

A return statement passes a value back to the immediate caller of the current function's call-frame. In the case of recursion, this immediate caller can be another invocation of that same function.

In most languages, if you don't use the return value of a function you called (recursively or not), either that return value gets discarded or it is a diagnosable error. There are some languages where the return value of the last function call gets automatically re-used as the return value of the current function invocation, but they don't differentiate between normal and recursive function calls.

Assuming unused return values get silently discarded, if you had written the code like this:

list *search_list(list *l, item_type x) {
  if (l == NULL) return(NULL);
  if (l->item == x)
    return(l);
  else
    search_list(l->next, x); // no return!
}

then search_list would only return a defined value for an empty list (NULL) or if the first item matches the value you are searching for. As soon as the function goes into the recursive call, you don't know what the result will be, because the result of the recursive call gets discarded.

Additionally, you promise to return a value from your function, but you have a path (the recursive one) where you don't specify what value to return. Depending on the language you use, this usually results either in a mandatory diagnostic or in undefined behaviour (which is shorthand for: anything can happen and that can change at any time without notice. Don't hold anyone but yourself liable if it screws up your most important presentation). There are some situations where the missing return value might appear to work, but that might change the next time you run the program (with or without recompilation).