Splay Trees: the Tree That Learns Your Habits

Balanced trees treat every key as equally likely to be asked for next. Real workloads don't behave that way: you re-open the same few contacts, a compiler looks up the same identifiers hundreds of times, a router forwards to the same handful of routes — the classic 80/20 pattern: 80% of accesses touch 20% of the keys, and what you touched recently, you'll likely touch again (locality of reference).

A balanced tree keeps a key you ask for a thousand times a day at depth 20, forever, because fairness to all keys is its only goal. What if the tree instead moved the popular keys near the root — automatically, with no counters, no statistics?

• One rule: after every operation — search, insert, even a failed search — splay the accessed node to the root via special rotations. Hot keys drift up; cold keys sink. The tree is its own cache.
• Zero bookkeeping: AVL stores a balance factor per node, Red-Black stores a color bit. A splay tree stores nothing — plain BST nodes. Simplest code of the three.
• Used in: Windows NT (memory management), GCC internals, caches, network routers — anywhere access patterns are skewed.
• The honest price: no per-operation guarantee. A single access can cost Θ(n). The tree can even be a chain at some moment. And yet — the total over any sequence is provably fast. Hold that thought for the next slide.

To splay node x, repeat until x is the root — asking, each round, three questions: does x have a grandparent? which side of the parent is x? which side of the grandparent is the parent?

• Zig / Zag — x's parent IS the root: one single rotation (right if x is a left child, left otherwise). The terminal move.
• Zig-zig / Zag-zag — straight line (LL or RR): rotate the grandparent edge first, then the parent edge. Two rotations.
• Zig-zag / Zag-zig — bent path (LR or RL): rotate the parent edge first, then the grandparent edge — the same two-rotation repair you used for AVL's bent (LR/RL) cases: it lifts x over the bend while preserving sorted order.

The subtle heart of the algorithm: in the straight-line case, splaying rotates the grandparent first. Plain "rotate x up twice" looks almost identical — and destroys the amortized guarantee. The showdown on the next slide exists to prove that this tiny ordering choice is everything.

BST search, then splay the found node — or, if absent, splay the last node visited before NIL. Even failures reorganize the tree (a failed lookup near k makes the whole neighbourhood of k cheaper next time).

BST insert (Lecture 7), then splay the new node to the root. Fresh data starts hot — usually the right guess. Below: every single rotation from L10·03's decision rule (zig / zig-zig), shown one at a time — no two rotations ever collapsed into one step.

• Amortized = worst case over a sequence, no probability. A single operation may be slow if the sequence stays fast.
• Potential method: pick Φ = "trouble stored in the structure." Amortized cost ĉ = actual cost + ΔΦ. Cheap ops charge the battery; expensive ops run on discharge.
• Back then we practised on toy examples and told you: "park the doubt — a structure is coming that cannot be analyzed any other way." It has arrived — you just watched it.

A splay tree makes no promise about any single operation — an access can cost Θ(n), and no worst-case-per-op analysis can say anything better. AVL had bf-arithmetic; Red-Black had color rules; the splay tree's only defense is: "the expensive access repaired the tree — the sequence as a whole stays cheap." That sentence IS amortized analysis. There is no other honest vocabulary for this structure.

The battery, concretely: Φ(tree) = Σ over all nodes of log(size of that node's subtree) — the "rank potential." A lopsided chain has HUGE potential (a fully charged battery of trouble); a balanced tree has small potential. An expensive splay of a deep node discharges the battery — the tree it leaves behind is flatter, and the discharge pays for the work. Exactly the inverter analogy: metered at the wall socket, every access reads O(log n).

With rank r(x) = log₂(size of x's subtree) and Φ = Σ r(x):

• Hence any sequence of m operations on an n-node splay tree costs O((m + n) log n) — deterministic, no probability, any adversarial order. (Compare: naive rotate-to-root admits sequences costing Θ(m·n).)
• Where the +1 and the 3 come from: only the zig-zig / zig-zag steps make the telescoping work — the proof is exactly a Lecture-3 potential argument, three pages long, and every tool it uses — ranks, Φ, telescoping — is already yours from Lecture 3. Weiss §11.5 has the full write-up; bring questions to consultation hours.
• Bonus (beyond the syllabus): splay trees are statically optimal — over a long skewed sequence they perform within a constant of the best fixed tree built with full knowledge of the frequencies.

Three trees, three philosophies: enforce balance strictly (AVL), enforce it loosely (RB), or don't enforce it at all and let the workload shape the tree (Splay).