Recursion vs Iteration Visualizer

What this shows

Two solutions to the same problem, run side by side from a shared play/pause/scrubber control: a recursive version, shown as its actual call stack pushing and popping frames, and an iterative version, shown as a loop variable updating in place. Both are real traces of real code, not animations built to illustrate a point — the call counts, stack depths, and results all come from actually running the algorithm.

Factorial vs Fibonacci — two very different stories

• Factorial is linear recursion — each call makes exactly one further call, so the call stack grows to depth n and no deeper. Recursive and iterative both do n units of work; the only real difference is that the recursive version needs O(n) stack space to hold every pending multiplication, while the loop needs O(1) — a single result variable it updates in place.
• Fibonacci is where the two approaches actually diverge. Naive recursive fib(k) calls itself twice, and neither call knows the other already computed overlapping subproblems — fib(15) alone makes 1,973 calls to compute a number the iterative loop reaches in 14 steps. That gap is O(2ⁿ) versus O(n), and it's the same exponential blowup covered in Algorithm Complexity Explained and plotted in Complexity Visualizer.

What memoization changes

Turn on Memoize recursive calls for Fibonacci and every fib(k) gets cached the first time it's computed — the next call with the same k returns instantly instead of re-exploring the whole subtree. fib(15) drops from 1,973 calls to 29, of which 13 are memo hits shown in violet. That turns the exponential recursion into a linear one — still using O(n) stack depth and now also O(n) memo storage, versus the iterative loop's O(1) of either — which is exactly why memoized recursion is usually described as trading time for space rather than beating iteration outright.

What the colors mean

• Amber — a frame currently active: pushed onto the stack, waiting on a call it just made.
• Green — a frame that has returned a value back to its caller.
• Violet — a memo hit: the function recognized it had already computed this exact call and reused the cached result instead of recursing further.

FAQ

Why does the iterative panel finish so much earlier?

Because it has so much less work to do. Both panels advance on the same shared step counter deliberately — the iterative side reaching "Done" and just sitting there while the recursive side is still hundreds of calls deep is the point. Nothing is sped up or slowed down to make them line up.

Why is the maximum n capped?

Naive recursive Fibonacci's call count grows exponentially, so fib(30) would mean well over a million recorded steps — the cap keeps every run fast to trace and the call stack panel readable. Turning on memoization removes the exponential blowup, so it unlocks a higher n.

Where does this connect to the rest of the toolkit?

See Big O Calculator and Sorting Algorithm Visualizer for the same idea — real, counted operations instead of abstract notation — applied to comparing complexity classes directly and to sorting.

Is anything I do here sent anywhere?

No — every trace runs entirely in your browser. Nothing here is ever sent to a server.