External Sorting & the Memory Hierarchy

Because the array isn't in memory — only a window of it is

Quicksort, heapsort, and friends assume O(1) random access: touch element 7, then element 4,000,000, then element 12 — all equally cheap. On RAM, true. But if the "array" lives on disk, every jump to a far-away element is a disk seek costing ~10 ms. A quicksort partition pass over 100 GB makes hundreds of millions of scattered accesses.

The OS will try to hide this with paging — loading 4 KB pages in and out of RAM — and the result is thrashing: the machine spends its life moving pages, not sorting. Days, not hours.

Grading 4,500 answer sheets on a small desk

You must arrange 4,500 answer sheets by roll number. The sheets are in the store room (disk). Your desk (RAM) holds only 750 sheets at a time. Walking to the store room is slow, and each trip you carry a fixed bundle of 250 sheets (a block).

You cannot "quicksort" 4,500 sheets on a 750-sheet desk. But you can: bring 750, sort them on the desk, tie them into a sorted bundle, return it — repeat 6 times. Then merge the 6 sorted bundles, carrying only the top few sheets of each to the desk. That, exactly, is external sorting.

• Seek time (t_s) — move the read/write head to the right cylinder. The big one: ~10 ms.
• Latency time (t_l) — wait for the platter to rotate the right sector under the head.
• Transmission time (t_rw) — actually stream the block of data.

So one input/output costs t_IO = t_s + t_l + t_rw. Seek + latency are pure overhead paid per access, not per byte — which is why disks reward few, large, sequential accesses and punish many, small, random ones.

The block: the unit of data read or written to disk in one go (one "bundle of sheets"). You can never fetch one record; you always fetch its whole block.

Read as many records as memory holds (M records), sort them internally with any good in-memory sort (quicksort, heapsort), and write the sorted chunk back to disk. Each sorted chunk is called a run. Repeat until the whole file is consumed.

while file not exhausted:
    read M records          // sequential read
    sort internally         // free! (vs I/O)
    write sorted run        // sequential write

Result: ⌈n/M⌉ sorted runs on disk. Nothing here ever jumps around the disk — every read and write is a straight stream.

Because merging two sorted lists only ever looks at the front of each list. To merge two runs of 750 records each, you don't need 1,500 records in memory — you need one block of each plus an output block:

• 2 input buffers — hold the current block of each run,
• 1 output buffer — collects merged records; written out when full,
• input buffer empties → refill with that run's next block.

Memory needed: 3 blocks, regardless of run length. Every block of every run is read once, sequentially. Merge is the only classic sort primitive with this property — that's why external sorting is always merge-based.

The lone run 15 was read and written in every pass while waiting for its turn. Wasteful? Could we have scheduled the merges differently so short runs are handled cheaply? Hold the thought — that is exactly the optimal merging of runs problem, and it leads to Huffman trees in Lecture 6.

Never more than 3 records' worth of blocks: two input fingers and an output collector. The file could have had 13 billion records — the memory bill for 2-way merging stays 3 blocks. Memory bounds the run size and merge width, never the file size.

Read 3 blocks (750 records) at a time, sort internally (heapsort/quicksort), write back:

6 runs of 750 records (3 blocks) each. I/O: 18 block-reads + 18 block-writes, plus 6 internal sorts.

Split the 750-record memory into two input buffers + one output buffer (250 each). Merge R1+R2 block by block: read one block of each run; merge into the output buffer; when it fills, write it out; when an input buffer drains, refill it from the same run. Then R3+R4, then R5+R6. Result of pass 1: three runs of 1,500. Pass 2: merge two of them → 3,000 (the third 1,500-run sits idle). Pass 3: 3,000 + 1,500 → 4,500. Done.

Check against what we've seen (2-way, m = 6): log₂ 6 ≈ 2.58 → 3 passes, 4 levels — matches the 4,500-record example. And each pass costs ≈ one full read + one full write of the file (36 t_IO there).

So total merge I/O ≈ 2 × (file blocks) × log_k m. The file size is fixed; the only lever you own is the number of passes.

• Step 1: Read 100 MB, quicksort it in RAM, write it out as a run. Repeat — 900/100 = 9 runs on disk.
• Step 2: Divide RAM into 10 buffers of 10 MB: 9 input buffers (one per run) + 1 output buffer.
• Step 3: Load the first 10 MB of each run; do a 9-way merge. Output buffer fills → append to the final file. An input buffer drains → refill with that run's next 10 MB.

Because 9 runs fit the buffer budget, one merge pass suffices: log₉ 9 = 1.

At ~150 MB/s sequential HDD speed that's ~24 seconds of I/O. The thrashing quicksort alternative makes random 4 KB page accesses — at 10 ms each, even one access per 4 KB of data would take ~38 minutes' worth of seeks (900 MB ÷ 4 KB ≈ 230,400 accesses × 10 ms). Same machine, same data: the difference is purely access pattern.