Sorting Race — Bet on the Faster Algorithm
Two sorting algorithms race the same array. Bet on the winner — the better big-O loses more often than you think. Free, no sign-up.
Six races. Same array, two algorithms — pick the one you think finishes first.
How to play
- Two sorts, one array. Back the one you think will finish first, then watch.
- The winner is the one using fewer operations — comparisons plus moves — not the one with the better textbook complexity.
- Read the size and the shape. Below about twenty bars the simple sorts win; on a nearly-sorted array insertion sort beats everything.
- A right pick pays 50, a wrong one costs 50. Six races, and you start with 100.
How it works
Two sorting algorithms race each other on the identical array, drawn as bars, and you bet on which one finishes first. Every round pairs an O(n log n) sort against an O(n²) one, so there is always an obvious favourite — and the obvious favourite is wrong about half the time. What actually decides it is the size of the array and its shape: insertion sort finishes a nearly-sorted array in a twentieth of the operations a naive quicksort needs, and below roughly twenty elements the constant factors outweigh the asymptotics entirely, which is exactly why real sorting libraries switch to insertion sort down there. The winner is decided by operation count, not by a timer, so the result is the same on any machine. Runs on your device, nothing is sent anywhere, and there is nothing to sign up for.
Operations means comparisons plus data movements, with a swap counting once, on plain textbook implementations. Real library sorts are hybrids and would win nearly every race, which is the point being made.
Frequently asked questions
Is the better algorithm not always faster?
Not at these sizes. Big-O describes how the cost grows, not what it is — and it hides the constant factor entirely. Measured over 400 runs of this game, betting on the better textbook complexity is right 3.19 times out of 6, against 3.00 for betting the same side every time. Two rules — a nearly-sorted array and a small array both favour the simple sort — are right about 4.8 times out of 6.
How is the winner decided?
By counting comparisons and moves, both computed before anything is drawn. The animation replays that count at the same rate on both sides, so the side needing fewer operations finishes first on screen for the same reason it wins. A visualiser that raced two real-time loops would give a different answer on a fast machine than on a slow one.
Why does quicksort do so badly sometimes?
It uses a last-element pivot, the naive version. On an already-sorted or nearly-sorted array that pivot is the worst possible choice and the partitions degenerate, so it does quadratic work on the input insertion sort handles fastest. Real implementations pick a median-of-three or random pivot precisely to avoid this.
What do the array shapes mean?
Random is shuffled. Nearly sorted is in order apart from a few adjacent swaps. Reversed is in exactly the wrong order. Few unique has only four distinct values, which is where a naive quicksort partition falls apart. Sawtooth repeats the same ramp several times.