Hazel performance analysis · ^report(13) · 2026-10-14

Telling the Request What Changed

On hazelgrove/hazel#2635 (livelits × modular editors), two commits pushed on 2026-10-14 make a slider release's request to the evaluation worker cheaper to build. This report measures them, and asks how to carry them to the branches that have diverged from #2635: hazelgrove/hazel#2469 (Andrew Blinn's modular editors, where the per-item statics they rest on come from), dev, and hazelgrove/hazel#2597 (the full livelits branch). It follows ^report(1)'s profile of a release, which put about 15 ms on building the request.

What a release sends

When a livelit's model changes (a slider released, a button pressed), the editor analyses the program again and sends the evaluation worker a request: the elaborated program and EvalInfo, the part of the statics the evaluator needs (for each expression, its elaboration, its co-context and its probe targets). On #2635 the request goes through ShareCodec, which replaces each value the worker already has with a small reference, found by its Merkle hash (ValueHash, remembered per object). So a request costs three things on the main thread: building EvalInfo, hashing what is new in the request, and encoding it.

^report(1)'s profile of a Kids' Choice release put about 15 ms on "building the request, almost all hashing its new values". Measured part by part, the hashing is the smaller share: on Full Body, building EvalInfo took 11.9 ms per release, hashing about 4 and encoding 2 to 11. Since 8fbc86c644, EvalInfo keeps each program's last projection and updates it, but to find what to update it walked both statics maps in key order, the last and the new, whole: some hundred thousand entries for the few hundred that change.

The change, in three steps

1. The kept projection (8fbc86c644, on #2635 since 2026-10-11). EvalInfo.of_info_map keeps the last projection per program and updates it by one walk over the old and new statics maps, comparing infos by identity, so the entries and most of the map that did not change are the same objects as before, and the request's hashing skips them. It pays off only when the new statics map shares its unchanged infos with the old one, which per-item statics do and whole-program statics do not.
2. DefStatics says what it changed (043508921b). DefStatics builds its merged map from the last one: it removes the old map of each item it analyses again or drops, adds the new one, and patches each item's spine root. It now records every key it touches and gives EvalInfo a note: these keys may differ between this map and that one. of_info_map uses the note when its kept projection is of exactly the note's base map (both maps matched by identity), and updates the projection at those keys alone; otherwise it walks, as before.
3. Unchanged spine roots are kept (9fb2bdf067). Per-item statics analyse each item with a hole for the rest of the program, so each item's root info is patched afterwards with the whole suffix below it: its elaboration, probe targets and co-context, which the evaluator reads to decide what it can reuse. That patch was redone for every item on every commit, as new objects, equal to the old ones for every item below the edit (149 of the 179 roots re-added on a Full Body release). A root is a function of the item and of what is below it; when those are the very objects of the last commit, the last root is kept, the same object.

On #2635

Each of up to four sliders on the eight Livelit Playground slides that have sliders was released five times, as the editor does it: the slider's model, an integer literal, changed in place, every id kept; statics through the app's own path (CachedStatics.init_compositional_term); the request built, hashed and encoded as the app builds it. Before is #2635 at 41897ec3a5, after at 9fb2bdf067.

The note's gain is in how the projection is built, so the same statics maps were also projected three ways on one build: rebuilt from scratch (as before 8fbc86c644), by walking both maps, and from DefStatics' note, on #2469's generated test programs (mega-1k, -2k and -4k, of about 1,000, 2,000 and 4,000 lines, a literal edited near the top, in the middle and near the end). Walking both maps costs about as much as rebuilding (8.4 against 6.7 ms on mega-4k): the walk's gain was never its time but what it kept, the objects the request then need not hash. The note gives both, in 0.67 ms.

On these generated programs the spine reuse changes statics by little: the medians before and after differ by 2 ms at most (31.5 against 29.7 ms, an edit near the top of mega-4k), and by under half a millisecond elsewhere (the table at the end). Why it helps the Playground slides more was not measured.

What is left: the roots above the edit

An item's spine root carries the whole program below it. An edit to item k leaves the roots below it as they were (and they are now kept), but changes every root above it, since each of their suffixes contains item k. Those roots are new, and the request must hash and copy them. On Full Body, the request's EvalInfo copies 808 nodes for the shirt-width slider (item 26) and 5,768 for the tongue-width slider (item 134), about 46 per item above the edit. The encoding does the same work before and after: for the eye-angle slider, 4,241 nodes copied before and 4,241 after; its time (7.2 and 11.1 ms) moved with the state of the heap, not with the work.

Carrying it to #2469

#2469 (modular-editors, at c1e4aeee4a) is where per-item statics come from, but it and #2635 have each moved on: #2469 rewrote DefStatics' walk on 2026-10-10, and #2635 added the request's sharing (ValueHash, ShareCodec) and the kept projection. The three steps were carried to #2469's head on a local branch, one commit each, and each needed one change:

1. The kept projection (port 128f3f303d). On #2469, of_info_map also reads the request's sample targets: a term holding a full-capture probe gets a witness of its own (SubexpProbeTargets.mark_full, Andrew's d81bb9ce25), so its samples are retaken. A projection is then a function of the statics map, probe_all and the set of full-capture probes, and a kept projection may be updated only under the same set. Carried as it is on #2635, it would answer a change of that set with the projection made before it; a new test does exactly that and fails, and passes once the set is kept beside the projection.
2. The note (port cdb799a376). #2469's DefStatics walk already returns what it changed, a list of (old map, new map) per item analysed again or dropped, which it replays to build the merged map (Andrew's 125dbf91eb). The keys to note are those maps' keys and each item's root: one fold over a list it already has. A program whose root is a module is reclassified afterwards, which rewrites keys of its own; there nothing is noted, and the projection walks.
3. The spine reuse (port 474b1e050e). #2469 has neither IdentityTable (a table keyed by an object's identity) nor ValueHash, both of which came in on #2635. The reuse is kept by the item's id instead, holding the item's elaboration to compare by identity; the test that recomputes each reused root compares the two by printed form, ids and all.

With the three ports, #2469's quick tests pass whole: 4,722 tests, in 353 s. The projection test checks, on six real edits of mega-1k, that the projection came from the note and equals a rebuild, and that under another full-capture set it is not the old one; the spine test recomputed 90 reused roots, none different. #2469 sends its request whole (it has no ShareCodec), so there the gain is in building the projection and in statics, not in hashing:

dev and #2597

Neither has per-item statics. Each commit analyses the whole program (Statics.mk), so every info in the new statics map is a new object: the kept projection's walk finds nothing in common and gives up (the existing test "statics rebuilt whole: the walk gives up" shows it), and nothing in the analysis knows which keys changed. #2597 already has the request's sharing (ShareCodec, ValueHash, IdentityTable), so once it has per-item statics the three steps carry as they did to #2469. dev has none of these yet; the order there would be per-item statics, the request's sharing, then the three steps.

How to carry it to another branch

• Start from per-item statics. Without an analysis that keeps unchanged infos as the same objects, none of the three steps has anything to keep.
• Write down what the projection is a function of. On #2635 it is the statics map and probe_all; on #2469 also the full-capture probes. A kept projection is updated only under the same inputs; anything else rebuilds it.
• Note a superset, never a subset. The note may name keys that did not change (an extra key costs one lookup), but must name every key that did: the keys of every item map removed or added, and every key patched after the walk (spine roots, module infos). Where a later pass rewrites keys the walk does not see, note nothing and let the projection walk.
• Match the note by identity, both maps. The note says how one map was built from another; it applies only when the kept projection is of exactly that base map.
• Reuse a patched root only when every input is the same object: the item's map, elaboration, hole and exports, and what is below it (the suffix, its probe targets and co-context). Compare an input that is rebuilt on every commit, such as the probe ids, by its keys.
• Test it the way the branch can. The projection from the note against a rebuild, over real edits; each reused root against a recomputed one; and, where the projection reads more than the map, a change of that input alone.

Tried and not kept

Keeping an EvalInfo entry that is equal by content as well as by identity (ValueHash.same): on Full Body it cut the entries re-added per release from 179 to 30, and the new objects in EvalInfo from about 13,100 to 2,200, but it made the whole request slower (a median of about 20 ms against 17, before the note), because comparing by content hashes as much as it saves. The spine reuse removes the same churn at its source.

What next

1. Offer the three ports to #2469, from the local branch, with this report's numbers.
2. A spine root need not carry the whole program below it for the request: find what the evaluator's reuse check needs from a root's suffix (its identity, or its hash), and send only that, so a release low in the program costs what one high up does.
3. Per-item statics on #2597, so that it can take the three steps.
4. Time a release in the browser, on #2635, before and after, to see these node numbers in the page.
5. The other half of ^report(1)'s commit path: the commit's redraw.

How this was put together

Branches: #2635 before at 41897ec3a5 and after at 9fb2bdf067 (the two commits, pushed 2026-10-14); #2469 at c1e4aeee4a, and with the three ports (128f3f303d, cdb799a376, 474b1e050e) on a local branch, not pushed. One probe, built on all four, as a test in the suite (PortData, with the parts only some branches have in a small module of its own per branch), run under node on a laptop with the test build (dune's dev profile); each build run twice, interleaved. Each series analyses a program cold, then edits one integer literal five or six times as the editor edits a model, every id kept. Times are performance.now() around each part. "New nodes" counts the objects of the new projection that are not objects of the last one; "nodes copied", the arrays an encoding output holds that are not references. The first edit after a cold start is the slowest (the engine warming up): it is in the table and out of the medians. The encoding split was measured in a separate pair of runs of the same two builds, on Full Body and Witch. Node is not the browser; times in the browser run longer.

The data

• The numbers, for programs too: every table in this report, and what its numbers measure, is also in this page as JSON, in its <script type="application/json" id="report-data"> element, so a reader or an agent that fetches the page alone has the dataset. The same, with any raw files that survive, is in 013/data/.