Why Is Quick Sort Faster Than Merge Sort?
This is one of the most common follow-up questions on Reddit and Stack Overflow: if Quick Sort and Merge Sort are both O(n log n), why is Quick Sort consistently faster in benchmarks? Big O hides constant factors and memory behavior — and that is exactly where the difference lives.
Cache locality is king
Modern CPUs are far faster than memory, so they rely on caches. Quick Sort partitions data in place, accessing contiguous memory that stays in cache. Merge Sort repeatedly copies elements into a separate buffer, jumping between the source and destination arrays and causing cache misses. On real hardware, cache behavior often matters more than the operation count.
In-place vs allocation
Quick Sort needs only O(log n) stack space and no large allocations. Merge Sort allocates an O(n) buffer, and that allocation plus the data copying adds real overhead that Big O notation ignores.
Smaller constant factors
Quick Sort's inner partition loop is extremely simple — a comparison and an occasional swap. Merge Sort's merge step manages multiple pointers and copies every element at every level. So even with the same number of comparisons, Quick Sort does less total work per element.
The caveat
Quick Sort's edge assumes good pivots; with bad pivots it degrades to O(n²). That is why production code uses Introsort (Quick Sort plus a Heap Sort fallback). And for data larger than RAM, Merge Sort's sequential access wins. See the full side-by-side comparison.
Frequently asked questions
If both are O(n log n), why is Quick Sort faster? +
Does Quick Sort use less memory than Merge Sort? +
See it in motion
Watch this algorithm and 9 others run step by step in our free interactive visualizer.
▶ Launch Visualiser