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

What the page keeps from one edit to the next

How much memory does a Hazel tab keep as you edit, and what keeps it? ^report(5) listed the forms a view takes on the page at once (its Html value, the tables of values shared with the evaluation worker, the virtual DOM tree last drawn, the DOM) and said that what memory these take had not been measured. This report measures a tab on #2597 (the full livelits branch) while one slider on the Livelit Playground's Full Body slide is moved again and again. The tab keeps about 90 MB more after every edit. The report says what that memory is, which of the page's caches and tables it is not, how that was found where the usual tool fails, and what is still open: which reference keeps it.

A tab, edit by edit

The slide is the Livelit Playground's Full Body: a figure drawn with the Drawing library and posed by sliders, each a user-defined livelit. The build is #2597 at c4e411f9c2, its head on 2026-10-14, in its development profile, which keeps function names (the profiler below needs them). A driver loads the slide in headless Chromium 155, with precise memory figures and garbage collection exposed, then sets the shirt-width slider to a new value and fires its input and change events, as letting go of a slider does. It waits until the picture has redrawn and four seconds more, forces two garbage collections and reads the page's live heap (performance.memory.usedJSHeapSize). The values run 67, 74, 81 and on, each 7 more, wrapping within 60 to 99, so no two edits in a row are the same.

Every edit adds between 76 and 173 MB, most about 80 to 95, with no sign of levelling off (Figure 1). This is the page's main thread only: the evaluation worker has a heap of its own, not counted here.

One run. The run with the undo history capped at 2 (below), which turns out to change nothing, read within 7 MB of this one at every edit and within 1 MB at the end: that is the noise between runs here, well below the differences that matter.

Update, later on 2026-10-14: it changed nothing because its cap never ran, so these were two runs of the same program; the noise estimate stands.

Not the caches

The page has a few caches that could keep whole programs, and each was the first suspect. Each was tried in a build of its own on the same commit, measured over the same 15 edits:

• The whole-program memos. Statics.mk remembers the statics of the last 16 programs it saw, and MakeTerm's three memos the last 8 parses (Core.Memo.general with a cache_size_bound). Held to one entry each, the heap still grows 73 MB per edit, and every redraw takes 18 to 31 seconds, since nothing is reused. The difference, about 19 MB per edit, is these memos filling up to their bounds over the first 15 edits; it stops when they are full.
• The undo history keeps 250 states. Capped at 2, nothing changes: 92 MB per edit. Its states share structure, so they are cheap.
  Update, later on 2026-10-14: not so. The cap applies only when cap_undo_stack is on (History.re), and it is off by default (Settings.re), so this build changed a number the code never reached, and the states, each a whole page model, are not cheap: they are the growth (Update).
• The projector view cache (ProjectorView.ViewCache) keeps a view for each projector's id and is never pruned. Turned off, 83 MB per edit, over six edits read three times; within what the other runs vary by.
• ShareCodec's tables. To send the worker only what it does not have, the page keeps the hashes of values it has sent (a Set) and the values the worker has sent it, by hash (a Map). Counted after every edit (Figure 3), they rise, reach their cap of 200,000 entries and reset, while the heap keeps growing through each reset. A census of every Map and Set on the page (Runtime.queryObjects) found these two to be by far its largest; the next largest had 20 entries.

Redraw: from setting the slider to the picture's markup changing. The view-cache run used the DevTools-protocol driver (below), whose redraws are not comparable with the others'.

Not a table keyed by ids

If no cache keeps the versions, something else does. A read of every module-level store on the page's main thread (in src/web, src/haz3lcore, src/language and src/util at c4e411f9c2: every ref, Hashtbl, map in a ref, memo and WeakMap) found that nothing on the ordinary editing path adds a version per edit by its construction. Every store sized like a program holds one version and is replaced by the next. Nor does any version keep the one before it: CachedSyntax keeps the inputs it was made from, never an earlier CachedSyntax; the editor's old statics are arguments, never stored; an evaluation result's streaming fields are cleared when the result lands; and the evaluator's state and its incremental cache refer to each other, but replay_state unties the two, so caches do not chain.

Update, later on 2026-10-14: the read covered module-level stores, not the app's own model, where the undo history lives: a list in the model, not a store, adds one version per edit (Update).

That left tables keyed by ids: an entry is replaced when its id comes again, but if ids change from edit to edit, old entries stay. A probe build registers each such table with a counter, and the driver reads all of them after every edit (the probe is count_id_keyed_tables.patch). None grows:

One run of 8 edits on the probe build. optimistic goes from 0 to 1 at the first edit and stays there.

What stays

With every table ruled out, the question becomes what the kept memory is. V8's sampling heap profiler answers by who made it: started after two warm-up edits (HeapProfiler.startSampling, one sample per 32 KB on average, dropping whatever the garbage collector frees) and stopped after four more, it reports the objects still alive, each with the stack that allocated it. The development build's bundle marks each function with its Reason source location, so each stack's innermost Hazel frame names a source file.

The 390 MB, about 98 MB per edit, is the growth itself, and it comes from every stage of an edit: the parse into terms, the statics and the types they make, the layout of the code, the evaluation worker's reply as decoded on the page, and the hashes of all of these. Nothing one cache would hold; rather, the editor's whole state as of each edit, kept. The profiler says who made what stays, not who holds it. That takes a heap snapshot.

Why not a heap snapshot

A heap snapshot (HeapProfiler.takeHeapSnapshot, the DevTools Memory panel) records every object and every reference, so it would show the chain of references from a root to the kept versions, and with it the holder. On this page it does not work:

The same in snap's Chromium 155.0.8059.39 and in Chrome for Testing's headless shell 155.0.8059.79, with the renderer's hang monitor off. The last row is the lead: ValueHash's memo is a WeakMap, and by its 98 MB in the profile it holds roughly two million entries (an estimate from bytes per entry, not a count). A build with that memo off, or bounded, may let a snapshot through, and the snapshot would name the holder.

Update, later on 2026-10-14: the lead held. With ValueHash's memo kept only within one synchronous run, a snapshot of Full Body after six edits completes in snap's Chromium: 2.3 GB of JSON in 75 s (Update).

The weak tables

Weak references are the usual suspect when memory is kept by a cache, so all of them were checked. Every weak structure in #2597 is a JavaScript WeakMap, used through js_of_ocaml; there is no OCaml Weak or Ephemeron anywhere.

A WeakMap's entry lives exactly as long as its key. That is the trouble with weak tables in general: what they keep depends on what keeps their keys, and that is written nowhere. So the fix, once the holder is found, is not a weaker reference. It is an owner and a lifetime: entries for the program shown now, dropped when the program moves on. Matthew's lesson from Adapton is the same: working within OCaml's garbage collector through weak pointers was a headache and error-prone, and the later memo system, with its demanded computation graphs, was built in Rust, with no garbage collector to work around.

Found on the way

The read of every store turned up five things that do not cause this growth but are worth a look of their own:

• A memo with no bound, in derivation mode only: stitch_term (derivation/DerivationExercise.re) keeps whole editors through Core.Memo.general without a cache_size_bound.
• AppStore.gc is never called; a TODO in Page.re says so. Where an MVU app's projector ids change, its model, update and view closures stay.
• StructureShareSexp's two maps are reset after each root, but not if a converter raises, and then they grow for good.
• HazelDB opens an IndexedDB connection for every save and never closes it.
• An agent's tool results keep two whole-program segments per edit in its chat.

What next

1. Snapshot without ValueHash's memo. Build #2597 with the memo off (or bounded), check that the growth is unchanged, and take a heap snapshot after a few edits. If it completes, its retainer paths from a kept version to a root name the holder.
2. Find a smaller slide that grows the same way, so that a snapshot fits even with the memo: one whose slider edits a livelit's model, measured as here.
3. Look outside the program's values: closures the browser holds on the render path (event listeners, timers, observers) keep everything they close over, and a snapshot would show them as roots.
4. Measure the same on #2635 (livelits with modular editors) and on dev, to see whether the growth is #2597's own.
5. Fix it with an owner and a lifetime for whatever holds the versions, and measure the same 15 edits again.

Update, later on 2026-10-14: steps 1, 3 and 4 are done and step 2 is not needed (Update): the snapshot worked; what the browser holds does not grow; #2635 keeps about 8 MB per edit and falls back, and dev has no Livelit Playground slides to measure but has the same undo history. Step 5 is Andrew's compaction, ported.

Update, later on 2026-10-14: the undo history

What keeps the versions. The page's undo history, History.Model.undo_stack in src/web/app/History.re, is a list of whole page models: before every edit, the page as it was, with every slide's editor and that editor's syntax, statics and layout. On Full Body that is about 90 MB per edit, kept by nothing else. The list is meant to stop at 250 states, but it is cut only when the setting cap_undo_stack is on, and Settings.re sets it off. So the history grows with every edit, and the build above that "capped it at 2" changed the 250 that this code never reaches.

Growth per edit is the slope from the 4th edit to the 12th, after the history has filled to its cap in the capped build. In every #2597 build redraws range from about 2 to 7 s, as in Figure 1, and do not separate the builds. #2635 was measured over 30 edits: it keeps 9 MB after the first and 94 MB after the tenth, falls back to 46 MB at the eleventh, and does so again at the 22nd; the likely cause is ShareCodec's tables starting over at their cap, not confirmed.

How it was found. In five steps, each taking one suspect off the list:

1. Not what the browser holds. Over six edits the heap grew from 400 to 900 MB while the page's event listeners (609), DOM nodes, detached ones included (47,923), observers and timers stayed exactly the same (counted with Memory.getDOMCounters and wrappers installed before the page's own scripts).
2. Not on #2635. The same sampled profile as Figure 4, over the same four edits, finds 37.5 MB kept on #2635: the worker's replies 14.5, ValueHash 9.8, ShareCodec 5.4, and almost nothing in types, statics, terms or layout, where #2597 keeps 390 MB.
3. A snapshot, at last. A probe build keeps ValueHash's memo only within one synchronous run (it starts over on the next microtask). The tab still grows 68 MB per edit, and a snapshot after six edits completes: 2.3 GB of JSON in 75 seconds.
4. Two snapshots, one session. V8 keeps an object's snapshot id for the life of the tab, so the objects in a snapshot after edit 6 whose ids a snapshot after edit 3 lacks were made by edits 4 to 6: 12.2 million objects, 257 MB. A dominator tree of the second snapshot (29 million nodes, computed in 4.6 s by a small C program) shows three copies of one 35 MB structure, Full Body's editor with its derived data. Two hang from the first and second entries of the undo history (Logged.Model.current, then undo_stack, then each entry's page model, its list of slides, and Full Body). The third is the projector view cache's one view, which is replaced, not added to.
5. Confirmed by a build: the undo history always cut to 2 states, the same 12 edits, twice (the table above).

The fix is Andrew's. Andrew Blinn met the same growth on the modular editors, on a much larger program, and fixed it in 6010128b7d (2026-08-26, "memory: kill the exponential co_ctx leak + compact undo snapshots"): each page model saved for undo has its syntax replaced by a small shared placeholder marked out of date, its statics and evaluation state emptied, and its result reset (since d93e482166, also his, it keeps what autosave keeps); undo rebuilds them from the program. And the cap always applies. That is why #2635, which has #2469 merged in, does not grow. dev has the same undo history as #2597.

Ported to #2597 (d41c7a0298; #2597's slide list is simpler than the modular editors', and the rest follows Andrew's code, less two caches #2597 does not have, as it stands on #2635), the tab keeps 159 MB after 12 edits, level from the third. The six Undo tests pass, as changed by Andrew to check the restored program text rather than the very same model. In the browser, an edit, an undo, a redo, a second edit and another undo restore the same picture and slider value as as built does, in five runs of each, alternating between the builds (median and range; on #2597 the five with the newest entry kept whole ran later, alternating with five more as built, which agree with these; the two #2635 rows ran one after the other):

Seconds from the key press (or the slider's change) to the picture's markup changing, read by the DevTools-protocol driver (undo_check.mjs), whose times run longer than heap_per_edit.py's, as in the caches table: compare them within this table only. On #2597, two of the as-built undos, and two of those with the newest entry kept whole, read 0.24 s or less where every other step there took 2.5 s or more: the driver catching a redraw from before the key press, so they are left out. On #2635 with the newest entry kept whole, every step reads 0.25 to 0.31 s: the redraw is there at the check's second look, 0.3 s after the key press. The console errors are one message, "HazelDOM: unrecognized attribute: Disabled", in every run, as built too; it comes about twice as often with the compaction, which fits more redraws.

What it costs. An undo now rebuilds what the saved state dropped. With the compaction, every redo took 6.0 to 6.5 seconds, about an edit's time, against 2.7 to 3.1 as built; half the undos did too (5 of 10, 5.8 to 6.5 s), and the other half took 2.0 to 3.0 s, as built does. Which undos stay fast was not examined; the whole-program memos, which remember the last few programs, may still hold the program being restored. So f8ae6f2b9c, also on #2597, keeps the newest entry of each stack whole, compacting it only when the next is pushed above it: the latest undo and redo then take what they take as built (median 2.6 s over five runs), for one page model more, 208 MB kept after 12 edits instead of 159. An undo further back still rebuilds. Andrew's note on the cap names the step after this one: undo entries that keep the program alone, not a page model.

#2635 and dev. #2635 had Andrew's compaction alone: every redo took 3.6 to 4.2 s and most undos 3.5 to 5.1 s, about three edits' time (an edit 1.2 s there, five runs); with the newest entry kept whole (032fe3aca6, on #2635 since 2026-10-15), every undo and redo is done within 0.3 s, the check's polling interval, and the memory kept over 12 edits is the same within about 1 MB (the undo times in the table above, the memory in the report's data). dev, which has the same undo history, is left to #2469's merge, which brings Andrew's fix (Matthew's call, 2026-10-15).

The update's data, in 014/data/update-2026-10-14/: each run's readings, the undo checks, the listener and node counts, #2635's profile by file, and, in holder/, the dominator reports and the tools (the snapshot index, the dominator tree in C, the drivers). The snapshots themselves, 4 GB, are not kept. In this page, under update_2026_10_14 in the report's data.

How this was put together

• Build: #2597 at c4e411f9c2, development profile. Each experiment is one build of that commit with one patch from this repository's patches/: memos_at_one_entry.patch, undo_history_capped_at_2.patch (and both together), view_cache_never_stores.patch, and the probe, count_id_keyed_tables.patch. Each applies to c4e411f9c2 as it is.
• Browsers: snap's Chromium 155.0.8059.39, headless, with --enable-precise-memory-info and --js-flags=--expose-gc; for the snapshot tests also Chrome for Testing's headless shell 155.0.8059.79.
• Drivers (in 014/drivers/): heap_per_edit.py, Python over chromedriver, for the 15-edit runs; and, in node 22 over the DevTools protocol with its built-in WebSocket, count_tables.mjs (the probe's counts), census_maps_sets.mjs (every Map and Set, with the view-cache run), sample_live_heap.mjs (the sampling profile) and snapshot_test.mjs. live_heap_by_file.py groups the profile by source file.
• Runs: one per build: 15 edits each, except the view-cache run (6, read after 0, 3 and 6), the probe (8) and the profile (2 to warm up, then 4). The heap is the page's main thread's, read after two forced collections and four seconds after the picture redrew. The two runs expected to match, as built and undo capped at 2, agree within 7 MB at every edit.
  Update, later on 2026-10-14: the update's runs are 12 edits each, in the same browser and with the same driver; its builds and patches are listed in its section.
• The profile's grouping: each sample is counted under the innermost frame on its stack that lies in Hazel's own code, skipping js_of_ocaml's runtime helpers (caml_*), and that frame is named by the Reason source location the bundle gives just above it. Generic helpers (OptUtil, ListUtil) count as their own file, under "other". The raw profile is 31 MB and not kept here; its summaries are in 014/data/, with every run's numbers.
• The audit of every store and weak table read the source at c4e411f9c2; it is the basis of the tables in Not a table keyed by ids and The weak tables.
• The numbers, for programs too: every number behind the figures and tables 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: each run's readings, the probe's counts, the census, the profile by file and the snapshot tests. The same numbers, and the profile's summaries, are files in 014/data/.
• Matthew Hammer and Claude, 2026-10-14.