Comparative Study of Heap Structures

Every structure in Lectures 16–20 implements the same abstract priority queue: INSERT, FIND-MIN, EXTRACT-MIN, and (for three of the four) UNION/MERGE and DECREASE-KEY. If the interface is identical, the only thing left to compare is how each structure pays for that interface — and that's a genuinely different story for each one.

Each new heap in this course existed to fix exactly one weakness of the previous one: Binary heap can't merge in less than O(n) → Binomial heap fixes merge to O(log n) by using a forest, not one array. Binomial heap's decrease-key is still O(log n) → Fibonacci heap fixes it to O(1) amortized by going lazy. Fibonacci heap's constant factors are painful in practice → Pairing heap fixes that by throwing away every bookkeeping field except three pointers.

Binary heap restores the heap property immediately after every operation (eager). Binomial heap is also eager but only within a UNION/consolidation call. Fibonacci heap is deliberately lazy — it defers all structural cleanup to the next EXTRACT-MIN. Pairing heap is lazy in the same spirit but pays as it goes on every MELD, with cleanup concentrated at REMOVE-MIN.

Binary heap: one complete binary tree, stored flat in an array. Binomial heap: a forest of binomial trees, at most one per degree — a direct mirror of binary counter bits. Fibonacci heap: an unordered forest of arbitrary-shaped trees, root list circular and doubly linked. Pairing heap: a single unordered multiway tree — no forest at all.

This is the single biggest structural fork in the family. Binary heap's array layout makes merging two heaps fundamentally rebuild-from-scratch work: O(n). The other three all store multiple independent trees (or a splice-friendly single tree), so merging is just relinking a constant or logarithmic number of root pointers: O(log n) for Binomial, O(1) for Fibonacci and Pairing.

Binary heap: zero extra fields (position is implicit in the array index). Binomial heap: parent, child, sibling, degree. Fibonacci heap: parent, child, left, right, degree, and a mark bit — the richest node of the four, and the reason its constant factors are the worst. Pairing heap: child, left, right — no parent, degree, or mark field, thanks to the "first child's left pointer is the parent" trick from Lecture 20.

Use a binary heap. No merge, no decrease-key-heavy workload, cache-friendly array layout, smallest constant factors of the four. This is what almost every standard library's default priority queue actually is.

Use a binomial heap if you specifically want a clean, well-understood, worst-case O(log n) merge with a textbook binary-counter analogy (Lecture 18's hospital-merger scenario) — or a pairing heap if you want O(1) actual-cost merges and don't need the binomial heap's more rigid degree structure.

Fibonacci heap is the textbook answer — it is the reason Dijkstra's algorithm has an O(E + V log V) bound at all. But per Lecture 20's honest caveat: most production graph libraries use a pairing heap or even a plain binary heap here, because Fibonacci heap's constant-factor overhead rarely pays off before graphs get very large.

Use a pairing heap. It is the structure real systems reach for when they need merge and decrease-key to be fast without paying Fibonacci heap's per-node bookkeeping cost — accepting, in exchange, that DECREASE-KEY's tightest amortized bound remains an open research question rather than a closed proof.

C++'s std::priority_queue and Python's heapq module are both plain array-based binary heaps — by far the most-used priority queue implementation in existence, precisely because most real workloads never need an efficient merge.

Common in purely functional programming languages (Haskell, Standard ML), where the forest-of-trees structure supports efficient persistent (immutable, structure-sharing) merges — a natural fit for a language where nothing is mutated in place.

Mostly appears in algorithms textbooks and research code as the structure that gives Dijkstra's, Prim's, and network-flow algorithms their best theoretical bounds. Rarely the production implementation, exactly as flagged in Lecture 19 — the per-node overhead outweighs the asymptotic win at everyday graph sizes.

The practical choice in graph libraries and competitive-programming implementations that specifically need decrease-key — chosen over Fibonacci heap precisely because it is simpler to implement correctly and faster in measured practice, the trade Lecture 20 built the whole lecture around.