Big-O Notation — The Upper Bound

When an experienced engineer says "that algorithm is O(n log n)" or "hash table lookup is O(1)," they're using a precise mathematical language that has become the universal vocabulary of algorithm analysis. This language—asymptotic notation—allows engineers worldwide to discuss algorithm efficiency without ambiguity, regardless of what programming language they use, what hardware they run on, or what specific inputs they consider.

Big-O notation is the cornerstone of this language. It's the most commonly used asymptotic notation, appearing in technical interviews, system design discussions, academic papers, and engineering documentation. Yet despite its ubiquity, it's often misunderstood—used imprecisely, confused with related concepts, or applied without genuine comprehension of what it represents.

This page will give you a complete, rigorous understanding of Big-O notation. Not just the intuitive shortcuts, but the mathematical foundation that makes those shortcuts reliable.

Before diving into definitions, let's understand why Big-O notation exists. What problem does it solve?

The measurement problem:

Suppose you want to compare two sorting algorithms. You could time them on your computer:

• Algorithm A: 2.3 seconds on 100,000 elements
• Algorithm B: 1.8 seconds on 100,000 elements

Is B better? Not necessarily. This timing depends on:

• Your specific computer's CPU, memory, cache
• The programming language and compiler
• The specific input data (already sorted? random? reverse sorted?)
• What else was running on your machine
• Even the current temperature affecting CPU throttling

The comparison becomes meaningless across contexts:

If someone tells you "my algorithm takes 5 seconds," you can't know if that's fast or slow without knowing:

• How big was the input?
• What hardware did they use?
• What language and optimizations?

What we need is a machine-independent, language-independent, input-size-relative measure of efficiency.

This is exactly what asymptotic notation provides. Instead of saying "takes 5 seconds," we say "grows proportionally to n²" or "grows proportionally to n log n." This tells you something fundamental about the algorithm that remains true regardless of hardware or language.

Let's start with the intuitive understanding that covers 95% of practical usage:

Big-O notation describes an upper bound on the growth rate of a function.

When we say an algorithm is O(n²), we mean:

• The algorithm's runtime grows at most proportionally to n²
• As n doubles, the runtime roughly quadruples (at worst)
• There exists some constant factor, but we don't care about it

The "at most" is crucial:

O(n²) means "no worse than proportional to n²." An algorithm that's O(n²) might actually be O(n) or even O(1)—Big-O gives an upper bound, not an exact characterization.

This is like saying "the meeting will last at most 2 hours." It could last 30 minutes, 1 hour, or 2 hours—but not 3. Similarly, O(n²) means growth won't exceed quadratic, but could be less.

Reading Big-O aloud:

• O(n) is read as "O of n" or "order n" or "linear"
• O(n²) is "O of n squared" or "quadratic"
• O(log n) is "O of log n" or "logarithmic"
• O(1) is "O of one" or "constant time"

The capital O stands for "Ordnung" (German for order), referring to the order of growth.

The intuitive understanding is essential, but the formal definition provides the precision that makes Big-O mathematically rigorous.

Formal Definition:

A function f(n) is O(g(n)) if and only if there exist positive constants c and n₀ such that:

f(n) ≤ c · g(n) for all n ≥ n₀

Let's unpack this carefully:

Why the constants c and n₀?

The constant c handles the 'proportional to' aspect. If f(n) = 5n and g(n) = n, then f(n) = 5·g(n), so we can use c = 5.

The threshold n₀ handles startup costs. An algorithm might have initialization that dominates for small inputs. For n = 1, a 'linear' algorithm might take 1000 operations due to setup. But for n = 1,000,000, that setup cost is negligible. We only care about asymptotic behavior—hence 'for large enough n.'

A concrete example:

Let's prove that f(n) = 3n² + 10n + 5 is O(n²).

We need to find c and n₀ such that 3n² + 10n + 5 ≤ c·n² for all n ≥ n₀.

Proof:

For n ≥ 1:

• 3n² + 10n + 5 ≤ 3n² + 10n² + 5n² (since n ≤ n² for n ≥ 1)
• = 18n²

So with c = 18 and n₀ = 1, we have f(n) ≤ 18n² for all n ≥ 1.

Therefore, 3n² + 10n + 5 is O(n²). ∎

What this tells us: The lower-order terms (10n + 5) and the leading coefficient (3) are all absorbed into the constant c. When analyzing algorithms, we can focus on the dominant term.

Big-O intentionally ignores several things. Understanding what's ignored—and why—is crucial for using Big-O correctly.

Why this is appropriate:

1. Constant factors are hard to measure precisely — Is a comparison 1 nanosecond or 1.5 nanoseconds? It depends on the CPU. Ignoring constants lets us make hardware-independent statements.

2. Lower-order terms don't matter at scale — If you're choosing between O(n²) and O(n log n), the lower-order terms won't change which is better for large n. The dominant term dominates.

3. Small inputs rarely matter — If your algorithm processes 1 million records, whether it's fast at n = 10 doesn't matter. Asymptotic behavior describes what matters at scale.

4. Simplicity enables comparison — By reducing complexity to a simple classification (O(log n), O(n), O(n²)), we can quickly compare algorithms without detailed analysis.

When analyzing algorithms, you'll derive expressions like 3n² + 17n log n + 42n + 1000. How do you simplify this to a clean Big-O expression? Follow these rules:

The Growth Rate Hierarchy:

Functions grow at different rates. Here's the standard hierarchy, from slowest to fastest growing:

O(1) < O(log n) < O(√n) < O(n) < O(n log n) < O(n²) < O(n³) < O(2ⁿ) < O(n!) < O(nⁿ)

Any function to the left is eventually dominated by any function to the right. This is what 'asymptotically' means—for large enough n, the ordering holds regardless of constant factors.

Even experienced developers make mistakes with Big-O. Here are the most common errors and how to avoid them:

Detailed mistake analysis:

Mistake 1: Confusing bound type with case type

Big-O, Theta, and Omega describe bound types (upper, tight, lower). Best-case, average-case, and worst-case describe input scenarios. These are orthogonal. You can have:

• Big-O of worst-case (most common usage)
• Big-O of best-case
• Big-O of average-case

Always be explicit about which case you're analyzing.

Mistake 2: Thinking Big-O measures speed

Big-O measures growth rate, not absolute speed. An O(n log n) algorithm with a constant factor of 1000 is slower than an O(n²) algorithm with a constant factor of 0.001 for n < 1000. Big-O tells you how they compare as n grows, not which is faster for any specific n.

Mistake 3: Mechanical loop counting

Not all nested loops give O(n²). Consider:

for i in range(n):
    for j in range(5):  # Fixed iterations, not dependent on n
        process(i, j)

This is O(n), not O(n²). The inner loop runs a constant 5 times regardless of n.

When analyzing code, you need to count operations as a function of input size ns. Here's a systematic approach:

Pattern 1: Simple loop

for i in range(n):      # n iterations
    do_something()       # O(1) each
# Total: O(n)

Pattern 2: Nested loops (independent)

for i in range(n):      # n iterations
    for j in range(n):  # n iterations each
        do_something()  # O(1) each
# Total: O(n) × O(n) = O(n²)

Pattern 3: Nested loops (dependent)

for i in range(n):         # n iterations
    for j in range(i):     # 0, 1, 2, ..., n-1 iterations
        do_something()
# Total: 0 + 1 + 2 + ... + (n-1) = n(n-1)/2 = O(n²)

Pattern 4: Halving loop

i = n
while i > 0:
    do_something()   # O(1)
    i = i // 2       # Halving
# Iterations: log₂(n), Total: O(log n)

Pattern 5: Loop with logarithmic inner work

for i in range(n):           # n iterations
    binary_search(arr, i)    # O(log n) each
# Total: O(n) × O(log n) = O(n log n)