When is skipping a subtree because its inputs compare equal actually cheaper than re-running it?

An equal-input bailout is the runtime asking one question before it descends: *have this subtree's inputs changed since last time?* If the answer is no, the subtree is not re-described and not compared; the previous result stands. It is the cheapest way to make an update visit less, and the easiest thing in a UI codebase to apply where it does nothing. ## What the check is, precisely - It runs **at a boundary** — a component position that the runtime has been told to gate. Some runtimes gate every component boundary by default; others gate only where you mark it. - It compares the **inputs the parent passes in**, typically with a shallow comparison: input by input, by identity rather than by walking nested contents. - It happens **before** the subtree's output code runs. Nothing below is described, so nothing below is compared. - It is a decision about **this pass only**. The next state write re-asks the question. What the check is *not*: a promise that the subtree will not update. A component skipped because its parent's inputs were unchanged still re-runs when its own state changes, or when something it reads directly changes. The gate only removes the *parent-driven* visit. ## Pricing both sides | | Paid | Proportional to | Frequency | |---|---|---|---| | Cost of the check | Every update that reaches the boundary | Number of inputs compared | 100% of updates | | Saving from the skip | Only when the check matches | Size of the subtree's pass | The check's hit rate | So the honest rule of thumb is: 1. Estimate the **subtree pass cost** — how many description nodes would be produced and compared below this boundary. 2. Estimate the **hit rate** — across the updates this app really performs, how often are these inputs genuinely unchanged? 3. Compare `hit rate x pass cost` with the comparison cost you now pay every time. Three consequences fall out of that arithmetic: - **Big and stable wins.** A dense subtree whose inputs change on one update in twenty is the textbook case; the comparison is noise against the pass it removes. - **Small or churning loses.** Above a handful of nodes, or above a boundary whose inputs change on nearly every update, you have added a comparison to every update and removed almost nothing. - **A never-matching check is pure cost.** If a caller constructs a fresh value — a new object, array or inline function — as an input on each update, a shallow comparison finds a different input every time. The gate runs, misses, and the subtree runs anyway. This is the most common way a bailout ends up costing more than it saves. ## Where the skip becomes reachable at all The gate can only help if the pass would otherwise have arrived. That has structural consequences: - If the frequently-changing state sits **above** a large static region, every update walks toward it, and a gate is the tool for stopping. If that state can instead live **below** the static region, the pass never goes there and no comparison is needed. - A subtree handed to a component as content it merely places, rather than described afresh by that component each update, tends to arrive with a stable identity, which is what makes an equality check able to match at all. - Under a reactivity model that tracks reads per binding, or a compiler that resolved which node each value lands in, the visited set is already close to the change itself. Adding gates there buys little and still costs the comparison. ## How this goes wrong in practice - **Blanket application.** Gating every boundary distributes a small tax across the whole tree in exchange for savings concentrated in a few places. - **Deep comparison to force a hit.** Swapping a shallow check for one that walks nested contents can cost more than the pass it avoids, especially on large inputs. - **Correctness drift.** A gate that compares by identity will hold a stale subtree if something was changed in place rather than replaced, which turns a performance tweak into a "why didn't the screen update" bug. - **No measurement.** Without a before-and-after on a real interaction, you cannot tell a 3% win from a 2% regression, and both are common. The discipline that survives contact with a codebase is simple: measure the interaction, find the update whose visited set is out of proportion to the change, place a gate at the one boundary that makes the pass stop short of a large stable region, verify that the inputs crossing that boundary are actually stable, and re-measure. Everything else is a comparison you pay for forever.