How would you decide where subtree-skip boundaries belong across a large application, and what would you ask the team to stop doing?

Blanket memoisation is one of the most reliably negative "optimisations" a frontend codebase adopts, because its cost is small, uniform and invisible, while its benefit is concentrated in a handful of places nobody measured. Leading this well is mostly about ordering the decisions. ## Step one: establish the cost model you are actually in Before any boundary is placed, answer for the runtime in use: **what must it visit for one update, given where our state is owned?** - If the visited set is already close to the change — a design that notifies only the bindings that read a value, or a compiler that resolved which node each value lands in — there is little for a gate to prevent, and adding one is a comparison with no matching saving. - If the visited set is "the subtree below wherever state was written", gates are meaningful, and the interesting question becomes *where* the frequently-changing state is written. - If the design re-checks everything each pass, gates at component boundaries are largely beside the point; the lever is the cost and count of bindings. This step is the one most teams skip, and skipping it is how a convention ends up applied in a runtime it cannot help. ## Step two: prefer structural fixes Ranked by how much they remove rather than how much they stop: 1. **Move the frequently-changing state down**, so the pass starts closer to what the change affects and never reaches the large region at all. 2. **Keep a large stable region out of the update path** — handed to the surrounding component as content it merely places, rather than described afresh on every update. 3. **Shrink what is described**: fewer wrapper levels, fewer per-item derived values built during mapping. 4. **Only then** gate a boundary, when a pass still arrives at a big region whose inputs genuinely do not change. Structural fixes hold without a contract. A gate is a standing obligation on everyone who calls that component. ## Step three: justify each boundary with numbers A boundary earns its place when an instrumented interaction shows: - a **pass cost out of proportion** to what the user changed, and - that cost concentrated in a **region below this boundary**, and - a **hit rate** high enough that `hit rate x avoided pass > comparison on every update`, and - a **stability check**: the values crossing that boundary are the same values from update to update, not freshly built ones. Then re-measure the same interaction. A gate that does not move the number is removed, not left in place as insurance. ## What to ask the team to stop | Stop doing | Why it is harmful | |---|---| | Gating every component by default | Distributes a per-update comparison across the whole tree for savings in a few places | | Counting gates as a quality metric | Rewards the behaviour that causes the regression and makes removal look like a step backwards | | Deepening a comparison to force a hit | Walking nested contents can cost more than the pass it avoids, on every update | | Shipping a gate with no before-and-after | Leaves nobody able to tell a small win from a small regression | | Treating a gate as a correctness tool | Gates decide what is visited; using them to suppress an update you do not want hides the real cause | ## The costs a lead should say out loud - **A stability contract spreads.** Once a boundary is gated, every caller must keep passing stable values, which pushes hoisting and caching outward into code that had no performance reason to change. - **Debuggability suffers.** "Why did this not update?" is the recurring bug class, and it is answered by understanding a comparison rather than by reading the feature's logic. - **Correctness risk exists.** A gate comparing by identity will hold a stale subtree when data was changed in place rather than replaced. - **Gates go stale.** A boundary justified by one tree shape stops paying when that tree changes, and nothing fails to make that visible. ## Guardrails worth institutionalising 1. A budget expressed as **visited work per interaction** for the two or three interactions that matter most, tracked over time — not a count of optimisations applied. 2. A rule that a gate arrives with its measurement, and a periodic sweep that deletes the ones whose hit rate has collapsed. 3. A shared vocabulary for reviews: ask *what does this update visit* rather than *is this component memoised*. 4. When evaluating a runtime, judge it by what it must visit per update for the product's real shapes, and treat throughput benchmarks on synthetic trees as close to irrelevant to that question.