Big O Complexity Calculator

Compare how algorithm complexity classes scale with input size.

Please note: Provided for learning and for checking your own working. Institutions differ in the conventions and rounding they apply, so confirm the method against your own course materials.

What the Big O Complexity Calculator does

Big O notation describes how an algorithm’s work grows with input size, ignoring constant factors. That makes it the right tool for predicting whether something will still work when the data gets ten times bigger — which is usually the question that matters.

Formula

O(1) constant; O(log n) logarithmic; O(n) linear
O(n log n) linearithmic — the bound for comparison sorting
O(n²) quadratic; O(2ⁿ) exponential; O(n!) factorial
Runtime ≈ Operations ÷ Operations per second

Inputs explained

Input	Unit	Required	Notes
Input size (n)	text	Yes	Scientific notation works, such as 1e6.
Complexity class	one of 9 options	Yes	—
Operations per second	text	Yes	A modern CPU core manages roughly 10⁹ simple operations a second.

How to use it

Choose Complexity class.
Enter Input size (n) and Operations per second.
Select Calculate.

Worked example

An O(n log n) algorithm on a million items at 10⁹ operations a second.

n: 1,000,000
Complexity: O(n log n)
Rate: 10⁹/sec

log₂(10⁶) ≈ 19.93, so about 19.9 million operations — roughly 0.02 seconds. The same input under O(n²) would need 10¹² operations, about 17 minutes.

Reading the result

"If n doubles" and "if n grows tenfold" translate the abstract complexity class into a concrete multiplier for the specific size entered — for O(n²) doubling always means 4× work, but for O(n log n) the multiplier itself shifts slightly as n grows, since log n keeps increasing.
"Largest n solvable in one second" flips the calculation into a capacity-planning question: given a time budget, how big a problem can this algorithm actually handle.

Assumptions and limitations

This assumes one fixed operations-per-second rate throughout — real hardware does not sustain a constant rate, since cache effects and memory bandwidth vary with data size and access pattern, so the estimate is an idealised floor, not a guaranteed figure.
Comparing operation counts across complexity classes ignores the constant factor entirely, which the notes flag directly — a large constant factor can make a "better" complexity class slower in practice at realistic sizes.

Common mistakes

Comparing runtimes across different algorithms' complexity classes without checking they use the same input size and operation rate — the table computes every class at the same entered n and rate specifically so the comparison stays fair; quoting just the notation elsewhere loses that.

Frequently asked questions

Is a lower complexity class always faster?

Not at small inputs. Constant factors matter, which is why insertion sort beats quicksort on tiny arrays and real implementations switch between them.

Why is O(n log n) considered the sorting limit?

Any comparison-based sort must distinguish n! orderings, and log₂(n!) is Θ(n log n). Beating it requires assumptions about the data, as radix and counting sorts do.