Heap Sort & Priority Queue Applications

We built the machinery: the shape + heap property, the array trick (PARENT/LEFT/RIGHT), BUILD-MAX-HEAP in a verified O(n), HEAP-INSERT (sift-up), and HEAP-EXTRACT-MAX (sift-down). All three run in O(log n) or better.

• Heap Sort: repeat EXTRACT-MAX exactly n−1 times on the same array — no extra memory, and the array sorts itself in place.
• Priority queues: wrap HEAP-INSERT and EXTRACT-MIN/MAX behind a scheduling interface — "always serve the most urgent item next," whatever "urgent" means for your problem.

Quicksort is fast in practice but has an O(n²) worst case on adversarial input. Merge sort guarantees O(n log n) but needs O(n) extra space for the merge step. Heap Sort guarantees O(n log n) and sorts in place — the one combination neither of the other two offers simultaneously.

BUILD-MAX-HEAP once (Lecture 16, O(n)). Then repeat: swap the root (the current maximum) with the last element of the still-unsorted region, shrink that region by one, and MAX-HEAPIFY the new root back into place. Do this n−1 times and the array is sorted, built entirely from the back forward.

• Guaranteed O(n log n) in the worst case, every time — no adversarial input degrades it, unlike quicksort.
• O(1) extra space — sorts in place, unlike merge sort's O(n) auxiliary array.
• Builds directly on operations you already trust — no new machinery beyond BUILD-MAX-HEAP and MAX-HEAPIFY from Lecture 16.

• Not stable. Equal-priority elements can be reordered relative to each other — the swap-with-last step has no memory of original relative order.
• Poor cache locality in practice. MAX-HEAPIFY jumps between indices i, 2i, 2i+1 — scattered memory access compared to quicksort's mostly-sequential partitioning, so heap sort is often slower in practice despite an equal or better asymptotic bound.
• Not adaptive. An already-sorted (or nearly-sorted) input gets no speed-up at all — heap sort does the same O(n log n) work regardless of how "easy" the input is, unlike insertion sort or adaptive variants of merge sort.

Walk into an ER and it doesn't matter who arrived first. A triage nurse assigns each patient an urgency level; the most urgent waiting patient is always seen next, no matter how long anyone else has been sitting there. A patient arriving in cardiac arrest jumps ahead of five people who arrived hours earlier with a sprained ankle.

That's exactly a priority queue: an abstract data type supporting INSERT (a new item arrives, with a priority) and EXTRACT-MIN/MAX (serve the most urgent item waiting). It is a generalization of a plain queue (FIFO, priority = arrival time) and of a plain stack (LIFO) — a binary heap is simply the standard, efficient way to implement it.

• O(log n) arrival and service — scales to large, constantly-changing queues without ever re-sorting everything.
• Priority, not arrival order, decides service — modeling urgency directly, rather than bolting it onto a FIFO queue with manual re-ordering.
• O(1) peek at "who's next" without removing them — useful for dashboards/monitoring ("what's the most urgent item right now?").

• No fairness guarantee. A steady stream of high-priority arrivals can starve low-priority items indefinitely — a real operational risk in scheduling systems, usually solved by aging (gradually increasing a waiting item's priority over time), which a plain heap does not do automatically.
• Changing an item's priority is expensive without extra bookkeeping (Lecture 16's decrease-key limitation) — if a waiting patient's condition worsens, updating their position needs an auxiliary index, not just a heap.
• No efficient "list everyone waiting, in order" — that requires repeated extraction (effectively a heap sort), not a cheap traversal.

Operating systems keep a ready-queue of processes keyed by priority (and often dynamically adjusted to prevent starvation) — "run the highest-priority ready process next" is the priority-queue problem verbatim.

Both algorithms repeatedly pick the cheapest available vertex/edge — implemented with exactly the min-priority queue we just animated, typically a binary heap, upgraded to a Fibonacci heap (Lecture 19) when decrease-key dominates the running time.

Routers prioritize latency-sensitive traffic (voice/video) over bulk transfers using priority queues on packets — the same "urgent jumps the line" behavior as the ER example.

Pathfinding's "open list" is a min-priority queue ordered by estimated total cost — always expand the most promising node next, exactly like always calling the most urgent patient next.

Print spoolers and batch job systems often support priority levels (e.g. a rush job) — small jobs or urgent flags jump ahead of a long queue of routine ones.

Discrete-event simulators keep a priority queue of future events ordered by timestamp — "process the next event in time order" is a priority queue keyed on time instead of urgency.