Skip to content
K Knidox Search…
Computer Science · Theory

Big-O Complexity Reference

Common time complexities, from O(1) to O(n!), with examples and a growth chart.

Ordered fastest → slowest growth. Lower on the list means it scales worse as the input grows.

O(1)Constantarray index, hash lookupexcellent
O(log n)Logarithmicbinary searchexcellent
O(n)Linearsingle loop, linear searchgood
O(n log n)Linearithmicmerge sort, heap sort, efficient sortsgood
O(n²)Quadraticnested loops, bubble / insertion sortfair
O(n³)Cubicnaïve matrix multiply, triple looppoor
O(2ⁿ)Exponentialrecursive Fibonacci, subset enumerationbad
O(n!)Factorialbrute-force travelling salesman, permutationsterrible
Growth as n grows (operations vs n)
Growth curves for O(1), O(log n), O(n), O(n log n), and O(n²) as n increases100 ops0 opsn = 1n = 10
O(1)O(log n)O(n)O(n log n)O(n²)

At n = 10 the curves already fan out: O(1) stays at 1, O(log n) ≈ 3, O(n) = 10, O(n log n) ≈ 33, and O(n²) = 100. The steeper the curve, the worse it scales.

Big-O notation describes how an algorithm’s running time (or memory) grows as the input size n grows, ignoring constants and lower-order terms. From best to worst the common classes are O(1), O(log n), O(n), O(n log n), O(n²), O(n³), O(2ⁿ), and O(n!) — lower means it scales better.

What Big-O really tells you

Big-O is a way to talk about how an algorithm behaves as the input gets large, not how many milliseconds it takes on your laptop. It captures the shape of the growth — flat, linear, quadratic, exponential — while deliberately throwing away constant factors and slower-growing terms. That is why 3n + 7 and 500n are both just O(n): as n heads toward infinity, only the dominant term matters.

Reading the table and chart

The list above is ordered from fastest-growing to slowest-scaling. O(1) and O(log n) are the classes you hope for; O(n) and O(n log n) are the workhorses of good algorithms; O(n²) and worse become painful as data grows. The chart plots the first five classes for n up to 10 so you can see the curves fan apart — O(1) stays flat while O(n²) climbs steeply.

Common time complexities, fastest → slowest

Ordered by how quickly the operation count grows with n. Lower on the list scales worse.

NotationNameTypical exampleScales
O(1)ConstantArray index, hash lookupExcellent
O(log n)LogarithmicBinary searchExcellent
O(n)LinearSingle loop, linear searchGood
O(n log n)LinearithmicMerge sort, heap sort, efficient sortsGood
O(n²)QuadraticNested loops, bubble / insertion sortFair
O(n³)CubicNaïve matrix multiply, triple loopPoor
O(2ⁿ)ExponentialRecursive Fibonacci, subset enumerationBad
O(n!)FactorialBrute-force travelling salesman, permutationsTerrible

How to use it well

Big-O by convention describes the worst-case asymptotic growth: the behaviour as n → ∞, for the least favourable input. Constants and lower-order terms are dropped, so O(n) beats O(n²) for large n even if the O(n²) routine wins on tiny inputs. When two algorithms share the same class, Big-O cannot separate them — you then compare constants, memory, and real benchmarks. As a rule of thumb, lower on the list above is better, and moving from O(n²) to O(n log n) is often the single biggest win available.

What does Big-O measure?
It measures how an algorithm’s running time or memory grows as the input size n grows, keeping only the dominant term. It describes scaling behaviour, not an exact time in seconds.
Which is faster, O(n log n) or O(n²)?
O(n log n) is faster for large inputs. At n = 1,000, n log n is about 10,000 operations while n² is 1,000,000 — a hundredfold difference that grows as n increases.
Why are constants and lower-order terms dropped?
Big-O describes growth as n → ∞, where the dominant term swamps everything else. So 3n + 7 and 500n are both O(n): the constant factor and the +7 stop mattering as n gets large.
Is Big-O the best case or the worst case?
By convention Big-O states an upper bound on the worst-case growth. Best-case and average-case are described separately, sometimes with Ω (omega) and Θ (theta) notation.
Does a lower Big-O always mean a faster program?
Not for small inputs. A hidden constant can make an O(n²) routine beat an O(n log n) one on tiny n. Big-O only guarantees the lower class wins once n is large enough.
What complexity is a good sorting algorithm?
Comparison sorts cannot beat O(n log n) in the worst case, which merge sort and heap sort achieve. Simple O(n²) sorts like bubble or insertion sort are fine only for very small lists.