Hazel performance analysis · ^report(8) · 2026-10-12

One slider, three ways: what modular editing saves

A question about the two livelits branches. #2597 has no modular editing, and #2635 has it, from #2469 (modular editors). How long does one slider change take on a complex picture, the Livelit Playground's Full Body slide? The hypothesis: #2635 is much faster, especially in its UX outline mode, showing only the slider and the picture, because it doesn't reprocess the unrelated code. A third set-up separates the two halves of that hypothesis.

The three set-ups

The Full Body slide draws a whole figure from about forty livelits: polygon editors for the shirt, pants, head, hair and shoes, choices and sliders for everything else, and a final ^picture of it all. Its text is the same on both branches. The change measured is one drag of the "arm length" slider, to a length not drawn before, so no change could be served from a cache of earlier pictures.

A against C is what modular editing does. C against B is what showing only the GUI does on top of it.

How long a change takes

From the slider's release to the redrawn figure, twelve changes in each set-up, after two warm-up changes:

The ranges don't overlap, so the order is not noise. A has c07bdacead (^report(7)), so its worker's stream messages are throttled as on #2635.

Where the time goes

Three changes in each set-up were profiled, the page's main thread and the eval worker together, and six more in B with the reuse check's fix (below). Times are milliseconds per change, profiled, so they run longer than the clock (the windows were 13.3, 1.8, 4.2 and 2.2 s). Rows overlap: a function's time includes what it calls.

The worker checks for reuse during the evaluation, so its evaluating row includes most of the check. B's extra worker time is the check, not more evaluation (below).

A: the whole program, analyzed again

On #2597, a slider change edits the program's text, since the livelit's model lives in it, and the page then runs statics on the whole program from scratch. That is 5.4 s of a 13.3 s profiled change. The page also rebuilds the whole code view (2.3 s) and turns the whole program into text (1.5 s). The worker's part, about a second, is the same as on #2635. This is the cost ^report(1) found on the much smaller Kids' Choice slide, where it was 3.5 s of statics against #2635's per-item 16 ms.

B: what dividing the program costs

The UX outline mode shows a GUI by opening its row as a cell: a small editor of its own. With cells open, the program is divided: the cells hold their items, and the rest stays in a base, and on every change the whole document is assembled again from them. Three costs follow, and none of them is in C:

• The worker's reuse check, about 2 s per change. The worker reuses what didn't change by checking each part of a new request against its cache of the last one. With the program whole, that check is a hash lookup, and the whole check takes milliseconds. Divided, about 120 parts fail the hash lookup but turn out to be equal, and proving that costs about 2 s (below). The worker ends up reusing exactly as much as in C.
• The autosave, 0.55 s. The app saves about a second after an edit. A change in C is usually over by then. In B it isn't, and the save, which turns the divided document into text and writes it out, lands on the main thread in the middle of the change.
• The cells' livelit views, about 0.46 s. They are drawn without the view memo that the whole program's editor uses (live_html instead of memo_view), so they cost more than C's views of the whole program (0.16 s).

So B is slower not because it shows less, but because of how it shows less. Its picture and slider are as cheap to draw as C's, but they come from a divided program.

The reuse check, counted

To see what the worker's check was doing, a temporary build of #2635 counted its outcomes and printed them per request: is there a cached entry, does the hash match, and if not, are the two elaborations equal anyway? The build is on a local branch and was not pushed. Per slider change, steady state:

The hash covers ids as well as structure, so it differs when a part is rebuilt with new ids. The slow path then compares structure, which is cheap, since it is memoized across checks (0–5 ms in all). It also compares the two parts' lexemes, by building a trace of every node in each, and that is the 2 s. It is quadratic: the program is a chain of lets, each holding the rest of the program, and each of the 122 enclosing lets builds its trace of a subterm of about 6,400 nodes.

The parts that change ids are the ones that contain the picture's item, drawn. Its own text doesn't change, but with its cell open, the item is elaborated again after every change, and the nodes the elaboration adds get fresh ids (for example, a let renumbered 62e92200… → 2ed82400…). Close the picture's cell and the slow path falls to 4 checks. With the program whole, the item keeps its ids.

So there are two fixes, and either would remove most of the 2 s:

• At the cause: a re-analyzed cell whose text didn't change should keep its elaboration's ids, or not be elaborated again at all. This is in how the divided program's statics treat open cells.
• In the check: compare lexemes in the same memoized walk as structure, so a part that only changed ids costs one visit, not one per enclosing let. This also guards every other case where unchanged code arrives with new ids. The trap was first noted on the woods in #2609's finding 24, the performance tracking issue. The same full-trace comparison, Exp.fast_equal_with_lexemes, also gates several caches in the page.

A fix for the check, tried

The check's structural comparison is cheap because it is memoized across checks, and two subterms whose hashes match are equal without a walk. The lexeme comparison had neither. So Equality gets a ~lexemes option: every walker, for each sort of node, also requires the two nodes' lexemes to be equal, inside the same hash shortcut and memo. The reuse check calls Exp.fast_equal_hashed_with_lexemes instead of the structural comparison followed by two traces. Other callers of Equality are unchanged.

Update, later on 2026-10-14: on today's head the save falls inside B's change again, and its print takes about 1 s (below).

The decisions are identical; only their cost changed. With the check cheap, a change in B also finishes before the autosave fires, so the save stopped landing in the middle of it. B's range was 1.06–1.9 s, with one change at 3.8 s.

Profiled again with the fix (six changes, the last column of the table), the worker's part of a change in B is now smaller than in C (884 ms against 1,056), and the autosave and the text conversion are gone from the change. What B still spends beyond C is on the page: the cells' livelit views without their memo (449 ms against C's 163) and collecting the stream's state (340 against 204). Profiled, B's window is still 1.2× C's, though on the clock the two are within 3%: the profiler slows some code more than other code (as in ^report(4)), so these rows say where the time goes, and the clock says how much.

The fix is on #2635 as cbdab791f5. It adds a test that the one-walk check agrees with the trace check (the same term with new ids: equal; a lexeme-only edit: not; a real change: not). The existing test that a lexeme-only edit invalidates reuse still passes, as do the Evaluator (524), Evaluator.Incremental (46), IncrSlides (13), CallMemo (6) and Equality (8) groups.

#2597 has no lexeme comparison in its check: it predates 7de3875cd8, which added the comparison to dev after an in-place edit of @@ to @@@ showed the old operator's result. So #2597 has neither this cost nor that protection. Corrected on 2026-10-13: #2597 doesn't need that protection. Its terms carry no lexemes at all (they came to dev with 500c466b44, which #2597 lacks), and it turns an unknown operator such as @@ into a hole of its operands alone. So @@ and @@@ make the same term and the same result, and nothing can go stale. Its check is already the cheap one: the hash lookup, then the memoized structural walk. dev compares lexemes by trace on every check, and without the hash shortcut, so the same fix would suit it, together with the shortcut.

Also in these profiles: the page indexes the whole program

C's profile showed another cost that grows with the program. When the worker's partial results arrive, the page combines them with an index of the elaboration: where each expression starts and ends. That index is built again for each new evaluation, so once per slider change, and it took 204 ms of C's 949 ms page update, profiled. Only expressions get an entry, but the walk also rebuilt every pattern and type. 8717564a5f, also on #2635, stops the walk there: 115 ms per change, profiled over six changes, with no change in what the index holds (a new test checks that the page never falls back to its slower full walk). The clock can't see it: twelve changes in C took a median of 1.37 s, against 1.23 s before, inside the noise of a check that runs every 200 ms.

Measuring it: two things that went wrong first

• On #2597, a slider set by a script does nothing. Setting the input's value and dispatching input and change events moves the slider on #2635, but on #2597 neither the label nor the picture changed in five minutes. A real pointer drag through WebDriver works on both, so every number here comes from real drags.
• On #2597, the picture is rebuilt, not patched. A MutationObserver watching the picture's elements saw no change on #2597, because after a change those elements are gone, and the new picture is new elements. So the redraw is detected by content instead: every 200 ms the page compares the large pictures' markup with what it was before the drag. That works whether a picture is patched or rebuilt.

Update, later on 2026-10-14: B and C with the same fixes

B and C, measured again the same way on #2635's head, 9fb2bdf067: the Full Body slide, the "arm length" slider, two warm-up changes and then twelve, each a real pointer drag to a length not drawn before, in headless Firefox 157.0 with a fresh profile per session. The harness of 10-12 did not survive, so it was rebuilt from this report's method (below). The picture's row now reads probe(drawn) while it is shown, so B keeps that row and arm_length's.

Each number is one session's median of twelve changes. The ranges are in the figure and in the data.

Where B's extra time went. Profiled (four changes in B on the head), the program's conversion to text (segment_to_string) was in 49% of the page's samples, about 1 s a change, inside the window. In C the same save comes just after the redraw. With the window held open 2.5 s past the redraw to catch it, save_current was 1,821 samples over three changes, about 600 ms each, and 239 (about 80 ms) with the fix.

Why the print was slow. To print a program with probes, the page wraps each probed term in its ^^probe(...) syntax (Triggers.refractor_seg_to_seg_with). A slide's top level is one long let ... in chain. At each node of it, the wrap sliced the list from its head (ListUtil.sublist) and took each child's range by walking down the chain (Skel.range): quadratic in the top-level items. And Segment.to_string calls it again on every nested segment while a probe is still unplaced, building each segment's skeleton. The fix slices an array, takes one end of a range at a time, and passes over any segment none of whose own pieces carries a probe. The output is the same: the 120 doc slides printed with their probes and parsed back pass, as do the divided-program, segmented-parser and FastParse tests.

What is left in B is the cells' livelit views, run on the page (live_html, about 340 ms of profile a change). That is the gap between the two rows' medians, where there is one.

A cross-check, on 2026-10-15. ^report(15), which sets Dress Up beside its livelits, measured the same slide and slider on #2635's newer head, 032fe3aca6, with the print's fix and the undo history's (^report(14)'s update). Its drag is not this report's: one real drag of 1.5 seconds (15 pointer moves of 100 ms), and release to redraw checked every 50 ms, eight drags after two warm-ups, in one session per set-up. Medians: C 1,091 ms (1,014–1,212), B 1,197 ms (1,056–2,206). The two again within the drift this update found between sessions; the numbers are in ^report(15)'s data.

What next

1. Bring the reuse check's fix to #2597, whose check has no lexeme comparison at all (above), and to dev, together with the hash shortcut. Corrected on 2026-10-13: there is nothing to bring to #2597 (above); dev remains.
2. Keep an open cell's ids stable when it is analyzed again without its text changing, or don't analyze it again. With the fix the check is cheap, but those parts still miss the hash lookup on every change; stable ids would put them back on it, on any slide with cells open (above).
3. Keep the autosave out of a change: save when the page is idle, not on a timer that can fall in the middle of an update. (Update, later on 2026-10-14: the save's print was also quadratic with probes, and is fixed: above. Saving when idle would still keep it out of a change.)
4. Give the cells' livelit views the view memo the whole program's editor uses.
5. Or a GUI-only view that keeps the program whole, drawing just the chosen livelits from the whole program's editor instead of opening cells. That would avoid all three costs at once.
6. A way to open a slide in UX mode from its address, for example ?mode=ux&show=arm_length,drawn. It would make these measurements, and demos, quicker to set up than clicking 41 rows off.

How this was put together

• Builds: #2597 at a15c6f0b65 (with ^report(7)'s fix) and #2635 at 57c928cef4, then with cbdab791f5 and 8717564a5f, dev builds, served locally. The Full Body slide's text is identical on both.
• Times: headless Firefox over WebDriver, a fresh profile per set-up, the slide opened at /fresh. Each change was a real drag of the "arm length" slider to a new length, the same twelve lengths in each set-up. The time runs from the slider's pointerup to the first moment a large picture's markup differed from before the drag, checked every 200 ms in the page. One set-up at a time, on one laptop.
• B's set-up: the outline switched to 🖼️ UX mode, then every GUI row's 🖼️ chip switched off except "arm_length" and "drawn", by clicking the outline's own controls.
• The reuse counts: a temporary build of #2635 (local branch perf/2635-reuse-diag, not pushed) that counted IncrEval.reuse_check's outcomes and printed them per request. Firefox copied the worker's console to a file (devtools.console.stdout.content). Its own sampling (an id trace of a few large subterms per change) slowed it, so the times in this report come from builds without it.
• Profiles: the Gecko profiler, sampling every 1 ms, over three changes per set-up, and six more each for B with the reuse check's fix and for C with the index's. The windows run from each pointerup to its redraw, from marks the page set. The worker's evaluation is run_scheduled_slice, and its reuse check reuse_check.
• 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 008/data/.