Charts · 09
Big O, in the keystroke
Big O is the shape of how work grows with input, and in an interface you meet it as the search box that starts lagging behind your fingers once the list gets long. Type into both fields below: they do the same job on the same list, and one of them has a single line that is quadratic. Then the classes themselves, to scale, and what each costs at a billion operations a second, which is the number that decides whether a feature ships.
What it feels like
selected.includes(id) O(n · m)
type to measure
selectedSet.has(id) O(n)
type to measure
Same list, same query, same render. The only difference is one line: an array includes walks the selected list for every item (n items × m selected), a Set answers in one step. Clear the box to search everything again; the worst keystroke is the first one, when every item matches.
The classes, to scale
| Class | Operations at n = 32 | At a billion a second | Typical of |
|---|---|---|---|
| O(1) | 1 | 1 ns | Array index, hash lookup, push to a stack |
| O(log n) | 5 | 5 ns | Binary search, balanced-tree lookup |
| O(n) | 32 | 32 ns | A single loop, a linear scan, rendering a list |
| O(n log n) | 160 | 160 ns | Merge sort, Array.prototype.sort, most good sorts |
| O(n²) | 1,024 | 1 µs | Nested loops, bubble sort, comparing every pair, naive layout of n items against n items |
| O(n³) | 32,768 | 33 µs | Triple loops, naive matrix multiplication |
| O(2ⁿ) | 4,294,967,296 | 4.3 s | Every subset, naive recursive Fibonacci, brute-force search |
| O(n!) | 2.63e+35 | 8.4e+18 years | Every ordering: the travelling salesman by brute force |
Hover a line or a row. Drag n up and watch which classes leave the chart.