Two pieces of code can produce identical results on a small test case and behave completely differently once real data arrives. Big O notation is how computer scientists describe that difference precisely — not by timing the code on one machine, which depends on hardware and gets outdated, but by describing mathematically how the number of operations grows as the input size grows.
What the “O” actually means
Big O describes an algorithm's growth rate — how the number of operations scales as the input size, conventionally called n, gets larger. It deliberately ignores constant factors and smaller terms, because the question it's built to answer isn't “how fast is this on today's hardware with this exact input,” it's “how does this scale” — a question whose answer doesn't depend on which computer you run it on.
The growth rates that actually matter
A handful of growth rates cover almost every algorithm you'll encounter, from best to worst as data grows:
- O(1) — constant. The same number of steps regardless of input size, like checking whether a list is empty.
- O(log n) — logarithmic. Operations grow very slowly as n grows — binary search on a sorted list, for example, which halves the search space with every step.
- O(n) — linear. Double the input, double the work — like scanning through every item in an unsorted list once.
- O(n²) — quadratic. Double the input, quarter the work explodes fourfold — typical of comparing every item against every other item, like a naive duplicate-checker.
At small n these curves look similar — the gap that decides which algorithm actually survives real-world data only becomes obvious once n gets large, which is exactly the regime Big O is built to describe.
Try it yourself — drag the slider to change the input size (n), and watch how many operations each growth rate actually needs.
Input size: n = 10
At n = 10, an O(n²) approach needs 100 operations — 10× more than the O(n) approach doing the exact same job.
A quadratic algorithm, O(n²), doing 100 operations for 10 items does 1,000,000 operations for 1,000 items — not 100× more work for 100× more data, but 10,000× more.
Why the gap between growth rates matters in practice
With small test data, an O(n²) algorithm and an O(n log n) algorithm might both finish in a fraction of a second — the difference is invisible. Scale the same input up to the size a real product actually handles (a million user records, a million rows in a database query), and the O(n²) approach can take literal hours where the O(n log n) approach takes seconds. This is precisely why an algorithm that “worked fine in testing” can grind a real production system to a halt the moment real usage arrives — the underlying growth rate was always going to catch up, it just hadn't yet at the scale being tested.
Why this matters beyond writing correct code
Any programmer can write code that produces the right answer. Writing code that still produces the right answer fast enough once real data arrives requires understanding, in advance, how an approach will scale — and Big O is the vocabulary that reasoning is built in. If computer science is something you or your child need explained with real reasoning about why one approach is better than another, not just syntax, that's exactly what our GCSE & A-Level computer science tutoring is for, and you can see the full learning pathway here.
Frequently asked questions
Why drop constants and smaller terms — doesn't that lose useful information?
Big O is deliberately built to answer one specific question — how does runtime scale as input gets very large — and constants matter less and less the bigger n gets. An algorithm that takes 5n steps and one that takes n steps are both O(n): for small n the factor of 5 might matter in practice, but as n grows into the millions, the difference between O(n) and O(n²) dwarfs any constant factor. Big O isn't the whole performance story — real engineers do care about constants — but it correctly predicts which algorithm wins once data gets large enough, which is usually the more important question.
Is a lower Big O always the better choice in practice?
Not automatically — for genuinely small inputs, an algorithm with worse Big O but a much smaller constant factor can actually run faster in practice, since the crossover point where the "better" algorithm starts winning might only arrive at, say, n = 10,000. This is exactly why some real-world sorting libraries switch between algorithms depending on how much data they're actually sorting, rather than always using the theoretically best one.
How is Big O actually used day-to-day by programmers, not just in interviews?
It's genuinely practical, not just an academic exercise — it's how a developer predicts, before writing or running any code, whether an approach will still work once real (much larger) data arrives, rather than finding out the hard way in production. Searching an unsorted list is O(n); searching a sorted list with binary search is O(log n) — a difference that's invisible with 10 items and enormous with 10 million, which is exactly the kind of decision Big O lets you make in advance.
Reader ratings & reviews
Rate this article across a few different things — your rating helps other readers, and helps us improve.
Was this article helpful?
Tell us what you think — a correction, a question it left unanswered, or a topic you'd like covered next.
About the author
Sudershan Soni
Founder & Lead Tutor at Mostak Services — an MSc-qualified Mathematics, Science, Computer Science & STEM tutor with 20+ years of professional experience, teaching students from 11+ and GCSE to A-Level and beyond, online worldwide.
Read full profile