A runtime that dirty-checks the whole component tree after every event slows as the tree grows - why, and how is the check narrowed?

## What dirty checking actually does This is the one model where a write is entirely ordinary. Nothing is intercepted, no handle is involved, no compiler rewrote anything. Instead the runtime, at moments it knows about, asks the whole tree a question: for every binding on screen, is the current value still the value I last rendered? Where the answer is no, it updates. Two things make that workable at all: - **Known trigger points.** The runtime must be told when to look. It learns about user events because it dispatches the handlers, and about asynchronous completions because the asynchronous entry points are wrapped so that finishing one also triggers a check. A write from an entry point the runtime does not know about is simply not noticed until something else triggers a check - which is exactly the classic "the value changed but the screen did not" report. - **Cheap comparisons.** Each binding keeps the value it last rendered, and the comparison is usually a reference or primitive check, so per-binding cost is tiny. The model's whole bet is that tiny times many is still acceptable. ## Why cost grows with the tree The walk is proportional to **bindings visited**, not to bindings that changed. A click that changes one label in a page with eight thousand bindings still costs an eight-thousand-comparison pass, and the numbers that matter in production are: - bindings per pass - grows with what is on screen, which is why large tables and long lists are where this model is felt; - passes per trigger - more than one when a check's own work changes something; - triggers per second - one careless high-frequency source, such as a pointer-move listener or a short interval, multiplies both of the above. What users feel is input latency: the walk happens between their action and the frame that shows its result. ## Why there can be more than one pass If the work done during a check changes another value - a derived field recomputed into a property, a callback that writes state - then the tree that was already walked may no longer be consistent, so the runtime walks again. It repeats until a pass finds no differences, and because a pair of values can chase each other forever, implementations cap the number of passes and report a failure to settle rather than hang. A binding whose expression returns a **freshly built object or a new function on every evaluation** never compares equal to last time, so it is a reliable way to produce that failure: the check finds a difference on every pass, forever. ## Narrowing the check The fix is not a faster comparison; it is fewer comparisons. In order of how much they buy: 1. **Check only marked subtrees.** Instead of walking from the root, mark the component whose inputs changed or in which the event fired, plus the ancestor path needed to reach it, and skip every unmarked subtree. Work now follows the changed region rather than the page. 2. **Make a change detectable at the boundary.** Skipping a subtree is only sound if the runtime can decide cheaply that the subtree's inputs are unchanged - in practice a reference comparison. So inputs must be new references when they change and stable references when they do not, which is real discipline on the producing side. 3. **Keep expensive work out of bindings.** A binding's expression is evaluated on every pass that visits it, so anything that builds, sorts, filters or allocates belongs in a value computed when its inputs change, not in the expression. 4. **Reduce triggers.** Take high-frequency sources out of the checked set, batch them, or let them update a narrow region directly rather than triggering a whole-tree check per event. 5. **Reduce what is on screen.** Windowing a long list cuts bindings per pass more than any of the above, because it attacks the multiplier directly. ## Confirming it rather than guessing The diagnosis is a counting exercise, and it is worth stating as one in an interview: measure **how long a check takes**, **how many passes each trigger causes**, and **how many bindings a pass visits**. If time per pass tracks the number of rows on screen, the walk is the problem. If passes per trigger is above one, something written during a check is changing values - find it, because it doubles everything. If triggers per second is high, the walk may be fine and the trigger source is the bug. Compare a busy screen against a nearly empty one in the same app: cost that scales with what is rendered rather than with what changed is the signature of this model. ## How it differs from the other three | | Dirty checking | The intercepted-write models | |---|---|---| | How a change is found | comparison after the fact | the write itself is the signal | | Cost driver | bindings checked, times passes | re-run subtree, or dependent count | | Needs special value types | no - plain objects are fine | a handle, a setter, or a compiled shape | | Typical failure | a write the runtime was never triggered for | a write that bypassed the tracked path | The honest summary is that dirty checking asks the least of your data and the most of your tree. It is the model that most rewards knowing exactly how large the checked region is, which is why the narrowing mechanisms above are not optimisations bolted on afterwards - they are how the model is expected to be used at scale.