Big-O notation.
Not how fast something is today, but how the work grows as the line gets longer.
When people ask if an algorithm is "fast", the useful answer is rarely a number of milliseconds — that depends on the machine. The better question is how the effort grows as the input gets bigger.
Big-O is the shorthand for that growth. It ignores the exact timing and captures the shape: does doubling the data double the work, barely change it, or blow it up?
- They’re basically the same?1
On a tiny input every approach looks fine — the piles are all small.
- 2
O(1): the pile never grows. A lookup by position costs the same at any size.
- 3
O(log n): the pile barely creeps up. Each step halves what’s left (binary search).
- 4
O(n): double the input, double the pile. A straight scan of the list.
- It’s off the chart!5
O(n²): the pile explodes. A loop inside a loop — 1k items ≈ a million steps.
- 6
On real, large data only the slow-growing shapes are still standing.
Why the shape beats the stopwatch
An O(n²) algorithm can easily be faster than an O(n) one on tiny inputs — the constants and overhead matter when n is small. Big-O deliberately ignores that, because it answers the question that actually bites: what happens when the data gets big?
Something that runs in a blink on 100 items can take hours, or never finish, on ten million. Big-O tells you which approaches will still stand up at scale.
Reading it in the wild
You will spot these shapes everywhere. A single loop over the data is usually O(n). A loop inside a loop is often O(n²) — a red flag on large inputs. Halving the search space each step (like looking up a word in a sorted dictionary) is O(log n), wonderfully slow-growing. Direct lookups by key are O(1).
Recognising the shape of your code is the first step to knowing whether it will survive real data.