Big-O Calculator

Big-O notation describes how the work an algorithm does grows as its input grows. It is the language of algorithm courses, interviews and code reviews, but the notation alone hides how dramatic the differences are. This calculator turns each complexity class into an operation count and a time estimate for the input size and machine speed you choose.

What Big-O describes

O(f(n)) says that, for large inputs, the running time grows no faster than f(n) times some constant. Constants and lower-order terms are dropped, so an algorithm doing 3n² + 10n steps is simply O(n²). That makes Big-O ideal for comparing how algorithms scale, and useless for predicting the exact speed of one implementation on one machine.

The eight classes

O(1) is constant: a hash table lookup or reading an array element. O(log n) halves the problem each step, as binary search does. O(n) touches every item once, like a linear scan. O(n log n) is the cost of efficient sorting such as merge sort and heap sort. O(n²) appears with nested loops over the same data, as in comparing every pair, and O(n³) with triple loops such as naive matrix multiplication. O(2ⁿ) comes from trying every subset, and O(n!) from trying every ordering, as brute-force route planning does.

From operations to time

Choose how many simple operations per second the machine performs; a modern CPU core manages very roughly hundreds of millions to a few billion simple operations, depending on what counts as an operation. The tool divides each class’s operation count by that speed and prints the result in nanoseconds up to years. When the number exceeds the age of the universe, about 13.8 billion years, it says so.

Chart and table

The chart plots the selected classes for inputs from 1 to 64 on a logarithmic scale, the only way to fit constant and exponential growth on the same picture. The second table keeps the machine speed and runs the selected classes for inputs from ten to one billion, showing where each one stops being practical: n² is fine at ten thousand and hopeless at a billion.

A worked example

With n = 100,000 and 100 million operations per second, O(1) takes 10 ns and O(log n), about 17 operations, 166 ns. O(n) needs 1 ms and O(n log n), 1,660,964 operations, 16.6 ms. O(n²) needs 10,000,000,000 operations and 1.67 minutes, O(n³) 116 days, and both O(2ⁿ) and O(n!) are “longer than the age of the universe”. That is the difference between a sort and a nested loop over the same 100,000 records.

What Big-O hides

Constants matter for real inputs. An O(n log n) algorithm with heavy overhead can lose to a simple O(n²) one for small n, which is why library sorts switch to insertion sort for short runs. Memory access often matters more than operation counts: scanning an array in order is many times faster than chasing pointers through a linked list with the same complexity. Measure with real data before optimising.

Using it in reviews and interviews

When you propose an algorithm, state its complexity and the input size you expect, then show the time from the table. “O(n²) on 50,000 rows is about 25 seconds at this speed” is a far stronger argument than the notation alone.

Related tools

• Bitmask Calculator works with constant-time bit operations.
• Connection Pool Calculator applies queueing maths to databases.
• Rate Limit Simulator models requests over time.
• Scientific Calculator handles logarithms and powers by hand.