The idea — coarsening merge sort
Plain merge sort recurses all the way down to subarrays of size . Coarsening (CLRS Problem 2-1) stops the recursion early: once a subarray shrinks to a fixed small size , you no longer split it — you sort that block directly with insertion sort, which is fast and cache-friendly on tiny inputs. The merges then rebuild the array from the sorted blocks as usual.
The whole result hinges on one question: is a constant, or does it grow with ?
The two phases and their cost
Split the work into the insertion-sort phase (sorting the bottom blocks) and the merge phase (combining them upward).
1. Insertion-sort phase. A block of size costs in the worst case. There are blocks, so the total is
2. Merge phase. Merging starts at blocks of size (not size ), so the recursion tree is shortened: instead of levels it has only levels. Each level still does merging work, giving
Total:
Reading the formula — the role of
| Regime for | Insertion part | Merge part | Total |
|---|---|---|---|
| = constant (e.g. ) | |||
| grows faster than | dominates | smaller | , worse |
When is a constant, and , so
The cutoff is invisible to the asymptotics — it only improves the hidden constant (which is why real libraries do it). The cutoff is provably worthwhile right up to ; beyond that the quadratic insertion-sort term takes over and degrades the bound.
How to apply (recipe)
- Identify the cutoff size and ask whether it is constant or a function of .
- Insertion phase ; merge phase .
- Add them and simplify, treating any constant as .
Mini-example
Merge sort that switches to insertion sort on every subarray of size . Here is constant: insertion phase , merge phase , so the algorithm is still
Exam trick: A fixed cutoff ("sort blocks of / of with insertion sort") is a constant — it cannot change the . The answer stays . Only a cutoff that scales with matters: is the break-even point (still ), and anything larger makes the insertion-sort term dominate.