Thread: Run-time execution for recursive functions.

The code isn't "copied" at all, there is only one instance of it in memory, the program counter just moves around. Each call to the function results in new instances of the local variables (local to that specific instance of the function [unless they are static]) pushed onto the stack. As far as the code itself goes, each time the function is called again, the program counter gets reset to point to the beginning of the function's code (the address of instruction we made the recursive call from is saved to jump back to after the current instance of the function ends). When the function ends, the current instances' local variables are popped off the stack and the program counter gets set back to the last saved value so we can pick up where we last let off.

... at least that's how I imagine it happens in my head.

Which is why you can overflow the stack with recursion that goes too deep (push, push, push, push....).

The main point being the compiler does absolutely nothing special to make a recursive call. It is exactly like any other call.

Originally Posted by Kempelen

I see, so as more local vars means more stack load to work with.
Does non-recursive function copy its local vars also in stack?

function does not know if it recursive or not.

Using one large funciton or several small ones is a compromise. If all functions are one long chain of calls (func1 calls func2 that calls func3), then the stack overhead is (a tiny bit) larger than if you put all the code for func1..func3 in one function - because each function call itself must also use some stack-space to store where to return to.

The general rules are:
1. Keep functions reasonably small - it makes them possible to read, and the compiler often optimizes small functions better than large ones.
2. A function should do one thing, and do it well.
3. If something is repeated several times in the code, make it a function.

--
Mats