Algorithms
Time Complexity
Iterative vs Recursive
Computational Efficiency
Algorithm Analysis

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.

Practice algorithms

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:

python
1def factorial_iterative(n):
2    result = 1
3    for value in range(2, n + 1):
4        result *= value
5    return result

Recursive version:

python
1def factorial_recursive(n):
2    if n <= 1:
3        return 1
4    return n * factorial_recursive(n - 1)

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:

python
1def fib_recursive(n):
2    if n <= 1:
3        return n
4    return fib_recursive(n - 1) + fib_recursive(n - 2)

Iterative Fibonacci:

python
1def fib_iterative(n):
2    a, b = 0, 1
3    for _ in range(n):
4        a, b = b, a + b
5    return a

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:

python
1from functools import lru_cache
2
3@lru_cache(maxsize=None)
4def fib_recursive_memoized(n):
5    if n <= 1:
6        return n
7    return fib_recursive_memoized(n - 1) + fib_recursive_memoized(n - 2)

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:

python
1def inorder(node):
2    if node is None:
3        return
4    inorder(node.left)
5    print(node.value)
6    inorder(node.right)

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
Course
Intermediate
27 lessons
15 hours
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 course
Track 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.

Practice algorithms