Hazel performance analysis · ^report(1) · 2026-10-10

Why a slider isn't instant yet

Hazel livelits, on the playground slides, measured 2026-10-09 to 11. Branch #2635 (livelits × modular editors), dev builds, headless Firefox.

Newest: the code editor re-checks only the tiles whose sorts can move: on each commit, a chunk's top-level tiles and its derivation tiles, not every tile it holds (on mega-4k, 25,852 → 270 tiles). Profiled, the code editor's part of a release went from 26 to 8 ms, but release to face moved only 3–5 ms (132 / 134 / 130 ms, with / without / with), which is within the noise. The profiler overstated this one. The gain grows with the program, not on this slide.

Before that: another profile. The face now waits only on the main thread: the commit, the redraw of the commit, then the redraw with the result. Its largest single item, in the worker, is fixed: reusing a cached result walked the whole reused code (the worker's evaluation 47 → 25 ms profiled). Release to face didn't move, since the worker is off its path.

Earlier: the three next steps from the 10-10 profile (the worker's responses 393 → 16 KB, no forced layouts, the problems panel per tile; release to face 140 / 142 ms, and about 3.2 s on #2597); a profile that found the result collector re-indexing the whole program (44 → 6 ms profiled); a view re-evaluates only the calls whose inputs changed (the face's first evaluation 43 → 12.5 ms); the evaluator's overhead (the face's view 60 → 42.5 ms, then a further 16–25% on a benchmark); requests carry only what changed (478 → 18.5 KB); #2597 is about 10× slower, without #2469; the worker's reuse check by Merkle hash (~410 → ~145 ms per release, and 2.7 → 0.41 s on a dev benchmark).

A slider change is the simplest thing a livelit can be asked to do: one number in one model changes, and something that depends on it redraws. In the Dress Up app it costs under a millisecond. In Hazel it now costs about 0.14 s, down from 4.6 s yesterday afternoon and from tens of seconds a few weeks ago. This report collects every performance problem we've found and fixed this fall, then looks at where the remaining time goes and what it would take to get to "immediate".

The same slider, at real speed

Both lanes start when the slider is released and finish when the picture shows the new value. They run in real time. The Dress Up lane finishes before you can see it move.

Where a release's time goes now

Profiled 10-11 on #2635 at 9129cd2774: six Kids' Choice releases, the first left out as a warm-up; profiled times are about 1.5× real ones. A timeline of the worker's messages, eight releases, gives the face's path: about 55–60 ms from the release to the request (the commit); about 35–40 ms in which the page redraws the commit, while the worker's answer arrives and waits; then about 45 ms from applying the result to the face's change. The face now waits only on the main thread: the worker evaluates while the commit is being redrawn.

Added later on 2026-10-14: measured part by part (in node, release by release), the hashing was the smaller share of building the request, 1 to 4 ms. Most of it was building the request's projection of the statics, by walking the last statics map and the new one, whole; that now takes under a millisecond on every Livelit Playground slide. ^report(13).

Fixed with this profile: reusing an evaluation walked the reused code. When the worker reuses a cached result, it copies the cache entry of every node below it into the new cache, and it walked the whole reused subtree to find them: on a slider release, nearly the whole program, 16 ms of its 47 ms evaluation. Entries are recorded only for nodes evaluated outside any call, so the walk now stops at function bodies, as the result collector's index does (#2635 9129cd2774, #2597 5286ba3b10). The worker's evaluation went from 47 to 25 ms and its work per release from 69 to 45 ms. Release to face did not move (154 / 143.5 against 140 / 142 ms), since the worker is no longer on the face's path. On real caches (275 entries on mega-1k; a generated program on #2597) the copy equals the full walk, kept in the tests as the reference.

Fixed since: the code editor re-checked every tile's sort on every commit. The code editor draws the program in chunks of whole lines and reuses a chunk's drawing while the sorts its tiles show (the colours) are unchanged. Every commit brings new statics, and that re-checked every tile of every chunk: a lookup and a mold rebuilt per tile, over the whole program. A tile shows two sorts, and each can move only for some tiles: the parser's only for a chunk's top-level tiles, since below them sorts follow the code itself; and the one statics refine only for derivation tiles. A chunk now lists those tiles once, when it is drawn, and a commit re-checks only them (#2635 31502d1e3d; the chunked code view is #2469's, so there's nothing to port to #2597). Tiles re-checked per commit: mega-1k 4,115 → 36, mega-2k 11,624 → 114, mega-4k 25,852 → 270. On a Kids' Choice release, profiled: the check 16 → 0.3 ms, the code editor 26 → 8 ms. But release to face, twelve releases each, with the change, without it, then with it again: medians 132 / 134 / 130 ms, means 148 / 152 / 145. That's 3–5 ms, inside the spread of single releases (107–206 ms). A test checks over 36 real edits that the narrow check never reuses a chunk the full one would redraw, and that it does redraw when a sort moves. In the browser, an edited derivation program drew the same classes, token for token, as a fresh load of the same text.

Next, by payoff: find which of the request's values are new on each commit, probably the elaboration's spine down to the changed item and the statics table's changed paths, and keep their identity (15 ms of hashing, profiled; started); and make the redraw of the commit cheaper, since the face's redraw waits for it. After the sort check, take these profiled numbers as upper bounds: code made of many small calls looks several times costlier under the profiler than it is.

Where the 0.4 s went (an earlier profile)

This profile is from 10-10 afternoon, at 0.43 s a release, before the diff requests, the evaluator and view changes, and the collector fix; the section above has the latest. It is kept because it shows the shape of a release.

A slider release in Hazel is a program edit. The new model is written back into the program text, and everything that depends on the text runs again. In Dress Up, a release changes one field of one object and redraws.

Two things stand out:

• The worker now takes about 145 ms per release (profiled), down from about 410 ms. Deciding what to reuse took about 280 ms of that; it now takes about 26 ms (below). Redrawing is now the largest cost, about 310 ms profiled. It isn't the browser's layout or DOM work (about 30 ms): it is Hazel rebuilding its view in JavaScript, once per redraw, and a release redrew six times (now four).
• Everything else is many medium costs, each touching the whole program somewhere: re-building terms, encoding a 478 KB request, decoding a 383 KB response, redrawing the editor.

Statics, which a "skip statics" toggle would remove, is now 16 ms of it.

How we got here

Every problem found this fall, and its fix

Tags: super-linear grows faster than the program; repeated work the same answer computed again; unshared copy a copy where a reference would do; identity lost a cache missing because objects were re-made; data size; scheduling.

Still open from #2609, without a fix: paste in the middle of a program falls back to the quadratic parser; long modules make MakeTerm worse than linear; the CLI hangs after an error report; a long paste can hang the page; and Shirt and Pants could lose a click. That one is now explained: each time the app re-measures its font (at load, when web fonts settle, on zoom), SetFontMetrics asks the editor to scroll the caret into view, and on a fresh slide the caret is at the top. A late re-measure jumps the editor about 10,000 px while you are scrolled down to the shirt, so the click lands on text. Fixed in 47f7f48397 (#2635): a font re-measure now keeps the scroll position. Not a performance bug, but on the same slide: the pants' editor drew them in its canvas's top-left corner, half cut off, because they were drawn from (0, 0); they are now centred (#2635 30758d0977, #2597 33126fdffe), and the outfit is unchanged.

What the list has in common

Work on the whole thing, inside a loop over its parts

Per character, re-process the whole run. Per let, re-analyze the whole definition. Per click, walk the whole program. Per use, evaluate the whole definition. Per variable, copy in its whole value. Per redraw, evaluate every view. Each is linear on its own; inside a loop it becomes quadratic, and nested it becomes exponential.

Caches that key on object identity break silently

Per-item parsing, the layout cache and the statics cache reuse work when they see the same objects as last time. One helper that re-made every object (MapPiece) turned all of them off at once, with no error, just slowness. A hash of the content (TypHash) survives copies. Identity is cheaper when it holds; a hash is safer when something upstream might copy.

Added later on 2026-10-13: identity or content is one axis of a design space of names: what each cache is keyed by, and what that key survives. ^report(11) sets it out for the evaluator, with Fumola's rule: what is edited gets a name that stays put while its value changes, and what is derived is found by its content.

Measure where the user is

Node said statics took 4 s on slides that froze Firefox for 30–108 s. The fixes that mattered most were found by profiling Firefox itself, one interaction at a time (scripts/profile_interaction.py), and by counting work instead of timing it (--count-passes).

What limits a slider now, and what it would take

The plan as it stood at 0.43 s a release, with what became of each step. The latest profile sets the next ones. Profiled times; real time is about 1.7× smaller.

1. Done: make the worker's reuse check cheap (~280 → ~26 ms). Merkle hashes on expressions plus remembered comparisons (above, #2673). The diff requests (4, below) now let it find most unchanged code by identity.
2. Started: redraw less, and only what changed (~310 ms of view building). The page rebuilds its whole view after every action, and each message from the worker was its own action: a release redrew six times, though only one of the worker's four messages had anything new to show. Now the reuse plan and the final stream ride with other messages, and a release redraws four times (#2635 b481a876e1, #2597 d92f446112). Main-thread work per release went from 1,141–1,427 to 935–1,051 ms (profiled, two profiles each); the time until the face redraws barely moved, because the redraws removed were off that path. Then each redraw reuses what it drew from unchanged inputs (#2635 51df91d5d7, #2597 a15af020ea). The code view's cache had the whole syntax record in its key, which is rebuilt whenever a result arrives, so the code re-rendered on three redraws of every release for nothing; it now keys on the parts it reads. Closing each livelit event handler's environment, and printing each probe's samples, are now remembered by the identity of the value. Each redraw's own view building, median of 8 releases: preview 18.5 → 14 ms, commit 32 → 25.5, face 90.5 → 83, final result 16.5 → 15; all four 157 → 138.5 ms (−12%). What is left is mostly real work: evaluating the face's view (~70 ms), and the commit's new text.
3. Dropped: keep a livelit's change out of the text path. The plan was to patch the elaborated program at the model's id and skip printing, re-parsing and re-checking, estimated at ~190 ms. Profiling steady-state releases before building it showed that path is now about 10 ms (profiled): MapPiece keeping identity, per-item parsing and per-item statics had already made it cheap. The one slow case was the first release after a load, which re-parsed everything; that is fixed (above). On #2597, without per-item statics, the step would still save its 3.5 s, but there porting #2469's statics is the better fix.
4. Done: send the worker a diff, not the program. Cyrus's suggestion. Unchanged values now go as references by Merkle hash: a release's request is 18.5 KB instead of 478 KB, and release to face went from 359 to 229–273 ms (above). The response, up to 383 KB, is still sent whole.
5. Started: make the face's own view cheaper, the largest single cost left. It is evaluated once per release, on the main thread (every other livelit's view comes from its cache), and the profile showed mostly the evaluator's own overhead, not the face's arithmetic. Two fixes so far: ids are minted as plain strings and compared as strings (7a5667e6f2), and the evaluator binds a run's constants once instead of re-applying itself to them at every node (857c293962). The face's view, warm, median of 8 evaluations over six releases: about 61 → 60 → 42.5 ms. A whole release (263 and 241.5 ms, median of 12, two runs) is within its noise. Then two more, on the evaluator's step machinery: its per-node stages are made once per run instead of eight closures at every node (2d35bb9e01), and two stages that only passed a value through no longer add a trampoline step for it (602498d7aa). The in-page probe could not see these (its medians vary by more than they save), so they were measured with a call-heavy program under node, the way views are evaluated, back to back:

   evaluator, 15 evaluations per run	min	median
   before the constants fix (7a5667e6f2)	583–585 ms	638–673 ms
   constants bound once (857c293962)	499	607–644
   + stages made once per run (2d35bb9e01)	450–469	529–541
   + pass-through binds skipped (602498d7aa)	408–426	461–479

   Then the bigger step: re-evaluate only the calls whose inputs changed, which took the face's first evaluation after a release from 43 to 12.5 ms.
6. A faster evaluator for the views that do change (~170 ms). The face's view must run. The wasm spike (#2490) measured the evaluator about 4× faster under wasm_of_ocaml on fixed-precision work.

A release is now the livelit's own update, a per-item re-parse and re-check, a small request, a cheap reuse check, re-evaluating the face, and redrawing it: the same shape as Dress Up's path, with the face's evaluation as the largest piece. Dragging is already there: while the finger moves, a livelit runs its own update and view on the page without any of this, which is why the slider itself follows the pointer.

How these were measured

• Headless Firefox over WebDriver, a fresh profile per run, dev builds of #2635, on Matthew's laptop. Wall times are from the slider's change event until the face's eyes redraw at the new size (scripts/slider_timing.py), four runs per build.
• Stage times come from the Gecko profiler, started from Firefox's privileged context after load and bracketed with performance.mark (scripts/profile_interaction.py). Profiled runs take about 1.7× longer than unprofiled ones.
• Message sizes: Worker.prototype.postMessage wrapped after load, with a listener for the worker's responses (scripts/worker_sizes.py).
• Dress Up: sixty input events on its eye-size slider in the same headless Firefox; Firefox timers have 1 ms resolution, and the median was 0 ms, the worst 2 ms.
• The dev reuse-check benchmark: a 400-definition program, evaluated, then its last literal edited with every id kept; only the incremental re-evaluation is timed, seven runs per build, under node.
• Release-to-face timing without the debug panel (scripts/release_timing.py): twelve releases per build, cycling values, the median reported. Request sizes for the diff requests came from a temporary probe on the encoded message in post_evaluate. The face view's evaluation was timed by a temporary probe that, on each release, evaluated the view eight more times and logged the median of those eight; a build's number is the median of six releases' medians, and the baseline and the id change were measured back to back. The evaluator benchmark is a temporary test group: a program that builds a 2,000-element list of tuples through recursive helpers and recurses 3,000 deep, run through evaluate_open 15 times under node (the same js_of_ocaml build as the tests), two runs per build, all builds back to back. The call memo was timed by a temporary probe logging each release's first face evaluation, 12 releases per build, the build without it measured in the same session; its correctness check captured the face's SVG after each of 13 scripted slider changes on each build and compared them. The timelines of a release wrap the page's Worker.postMessage and listen to the worker's messages, and watch the face's eye with a MutationObserver, timing each against the release. Redraws were counted with a temporary probe logging each action and each view.
• When a fix's gain is small, it is timed A/B/A: twelve releases with the change, twelve on the same commit without it (rebuilt in place, about 11 s), twelve with it again, back to back. The code editor's sort check is why: the profiler gave it 16 ms per release, and removing it saved 3–5 ms. Code made of many small calls slows down more under the profiler than the rest. The tiles re-checked per commit on the mega programs were counted by a temporary print in the test.
• Scripts are in ~/hazel-livelits-modular/scripts, untracked. Details and discussion: hazelgrove/hazel#2609, findings 10 and 11.
• 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 data/.