Big O Tracks Growth, Not Seconds
Big O notation describes how an algorithm’s work changes as the input gets larger. The input size is usually written as n: for a contact list, n might be the number of names to search. Big O does not predict an exact runtime on a particular computer. It focuses on the shape of the growth, especially when n becomes large.
That makes it useful for comparing approaches without knowing their hardware or programming language. An algorithm that checks each item once has O(n) growth: twice as many items means roughly twice as much work. A nested scan that compares every item with every other item can have O(n²) growth: doubling the list can bring about four times as many comparisons.
Why Small Tests Can Mislead
For a tiny input, the nested scan may feel instant. The trouble appears as the workload expands: each new item adds comparisons with all the items already present. A single loop can therefore be a better choice at scale, even if both versions seem equally fast in a quick test.
Big O also suppresses constant factors and smaller terms. An O(n) method that performs many operations per item may be slower on a small dataset than an O(n²) method with very little overhead. The notation is a guide to long-term growth, not a stopwatch or a complete benchmark.
The Practical Payoff
When a service slows as its users or records grow, Big O helps developers ask whether the underlying work is scaling poorly—not just whether a machine needs more power. Choosing a method with gentler growth can postpone that slowdown, because the cost of each additional batch of data rises much more slowly.
