Comparisons

Quick Sort vs Tim Sort

Updated June 8, 2026 6 min read

Quick Sort vs Tim Sort raises a great question: if Quick Sort is so fast, why do Python, Java, and JavaScript use Tim Sort by default? The answer is that real-world data is not random, and library sorts need to be stable and predictable — areas where Tim Sort shines.

The trade-off

Quick Sort is often fastest on uniformly random arrays, but it is unstable and has an O(n²) worst case. Tim Sort is stable, guarantees O(n log n), and reaches O(n) on partially-sorted data by detecting runs. Since real inputs are frequently partially ordered, Tim Sort often matches or beats Quick Sort on practical workloads.

Why stability tips the scale

A general-purpose library sort must behave predictably for everyone. Stability enables correct multi-key sorting, which countless applications depend on. Quick Sort cannot offer stability without giving up its in-place advantage, so language designers chose Tim Sort (for objects) and reserved Quick Sort variants for primitives where stability does not matter.

The verdict

For a custom hot loop on random primitive data, Quick Sort or Introsort may be faster. For a default that must be stable and robust on real data, Tim Sort wins — which is why it is everywhere. See what algorithm Python uses for the full story.

Frequently asked questions

Is Tim Sort faster than Quick Sort? +
On partially-sorted real-world data, often yes, because Tim Sort detects existing runs and approaches O(n). On uniformly random data, Quick Sort is usually faster, but it is unstable and risks O(n²).
Why do languages use Tim Sort instead of Quick Sort? +
Because Tim Sort is stable, guarantees O(n log n), and is optimized for the partially-ordered data that appears in real applications. Stability is essential for predictable library behavior.

See it in motion

Watch this algorithm and 9 others run step by step in our free interactive visualizer.

▶ Launch Visualiser

Related articles

← Back to all articles