All topics
38

Why comparison sorts stop at n log n

Tier 1Locked

1. The problem

You have written several sorts by now. Bubble sort, selection sort and insertion sort take O(n2). Merge sort and quicksort take O(n log n), quicksort on average. For a whole family of sorts, a sort that runs in O(n) on any list is impossible, and there is an exact reason. Every sort you have seen learns about the order in one way. It compares two elements, asks "is this one smaller?", and decides what to do next from the "yes" or "no". It has no other information about the order. This lesson shows why that limits the speed and computes the limit.

This code won't go into production. You need it to see when to stop speeding up a comparison sort and use a different kind of sort instead.

This step is part of the paid track

The first 33 steps are open to everyone: lesson, exercise and tests. This one opens with full access. Start with a free account and the free steps.

Create a free accountSee what is included

Recognise it

Non-comparison sort (counting / radix)

Say these words and it is this pattern

  • keys are integers in a small known range
  • sort ages, grades, or bounded counts
  • need O(n) and comparisons are the bottleneck
  • sort by digit or fixed-width key
  • n large but the value range is much smaller than n

Looks similar, isn't

n values with keys under k gives O(n + k). Radix sort costs O(d times n) across d digits.

On LeetCode

No LeetCode problem asks you to prove this limit. It tells you when to stop looking for a faster comparison sort, and a problem that demands O(n) time on numbers, like Maximum Gap, needs the counting or radix sort from lessons 39 and 40.

We use necessary cookies to run the site (sign-in and language). If you accept, we also load Google Analytics to see which pages are used, and Google reCAPTCHA to keep spam off the contact and bug-report forms. Privacy policy