Do iterative and recursive versions of an algorithm have the same time complexity?
Data Structures & Algorithms practice on Codemia
Step through 300 algorithm problems with animated visualisers that show the data structure changing as the code runs.
Introduction
Iterative and recursive versions of an algorithm often have the same time complexity, but not always. The answer depends on how much work each version performs, how many subproblems it creates, and whether the recursive version repeats work that the iterative version avoids.
When The Time Complexity Is The Same
If both versions process the same number of elements and do the same amount of work per element or per state, they usually share the same asymptotic time complexity.
Factorial is the classic example.
Iterative version:
Recursive version:
Both perform one multiplication per level, so both are O(n) time.
The recursive version does have extra call overhead, but that does not change the asymptotic class. It changes the constant factor.
When The Time Complexity Is Different
Recursion can create repeated subproblems if the implementation is naive.
Naive Fibonacci is the standard example:
Iterative Fibonacci:
The iterative version is O(n). The naive recursive version is exponential, commonly described as O(2^n), because it recomputes the same values many times.
So recursion itself is not the problem. Repeated work is the problem.
Memoization Can Change The Result
If you memoize the recursive Fibonacci version, the time complexity becomes linear again:
Now the recursive and iterative versions are both O(n) time, even though one uses recursion and the other uses a loop.
That is why the right question is not "recursion or iteration" by itself. The real question is how much work the algorithm structure causes overall.
Space Complexity Often Differs Even When Time Matches
Even when time complexity matches, space usage often does not.
For factorial:
- iterative version uses
O(1)auxiliary space - recursive version uses
O(n)call stack space
This difference matters in practice because deep recursion can overflow the stack even when the time complexity looks fine.
So if someone says two versions are "equally efficient," ask whether they mean time only or both time and space.
Tree And Graph Problems Often Favor Recursive Structure
Some problems are naturally recursive, such as tree traversal:
An iterative version exists too, typically using an explicit stack. The two versions often have the same asymptotic time complexity because both visit each node once.
In those cases, recursion may be clearer even if the iterative version avoids function-call overhead.
That tradeoff is about clarity and stack behavior, not necessarily asymptotic time.
A Good Rule Of Thumb
Iterative and recursive versions usually have the same time complexity when:
- they solve the same set of subproblems
- each subproblem is solved once
- the per-step work is comparable
They differ when recursion:
- duplicates work
- branches into overlapping subproblems
- performs extra recomputation that the iterative version avoids
This is why some recursive solutions are elegant and efficient, while others are elegant but disastrously slow.
Common Pitfalls
The biggest mistake is assuming recursion automatically means worse time complexity. That is false. Many recursive algorithms have the same time complexity as their iterative equivalents.
Another mistake is ignoring repeated subproblems. Naive recursive code can look compact while hiding a huge explosion in total calls.
People also confuse time complexity with practical runtime. Two algorithms can both be O(n) while one is slower due to recursion overhead or stack behavior.
Finally, do not forget space complexity. Recursive and iterative versions often differ there even when their time complexity matches.
Summary
- Iterative and recursive versions often have the same time complexity, but not by default.
- They match when they do the same total work and solve each subproblem once.
- Naive recursion can be slower when it repeats work, as in recursive Fibonacci.
- Memoization can turn a slow recursive algorithm into one with the same asymptotic time as an iterative version.
- Even when time matches, recursive versions often use more stack space.
Related reading
- Do minimum depth, spanning trees algorithms exist?
- Do problem constraints change the time complexity of algorithms?
- Do variables declared in loop make space complexity ON?
- Do we need to use beam search in training process?
- Do javascript loaders replace the need to do script combining?
- Do keeping cassandra fetch limit low make any improvement in performance?
- Does a HashMap with string keys really have a lower time complexity than a Trie?
- Does A work with negative weights as long that the heuristic is admissible?

DSA Fundamentals
Master algorithmic patterns and data structures through hands-on LeetCode-style problems - from arrays and hashing to dynamic programming and advanced graphs.
View the courseTrack what you have practised
A free account saves your progress, solutions and study plan across every problem on Codemia.
Data Structures & Algorithms practice on Codemia
Step through 300 algorithm problems with animated visualisers that show the data structure changing as the code runs.