pi-mono/packages/chord/docs/benchmarks.md

# Chord v2 benchmarks

Light benchmarks of hot paths, run by hand (not in CI), recorded per slice for later slices to compare against
(owner, 2026-10-22). Each section names its script, the machine and what the numbers include.

## Slice 3a: remote objects over one link

Script: `test/bench/links.ts`, run from `packages/chord` with
`node --conditions=source --experimental-strip-types --expose-gc test/bench/links.ts` (about 15 s). Node 24.4.1,
Intel Core i9-13900, one process: server and client host on one memory link (`queueMicrotask`), every case once per
codec, side by side.

Payloads, modelled on p2: entries `{ id, text, author, at }` in one document of a local store, exposed by a remote
view; "1,000 items" are entries with 80-character texts (the notes list), "500 KB" are 500 entries of 960 characters
(a conversation document). Commits are server-side method calls (one transaction each) on the store.

What the numbers include:

- *first hold to live*: the first `client.get`, which also activates the view on the server; one sample, so it moves
  by a few hundred µs between runs (JIT and collector state).
- *hold to live (mean of 100)*: further `client.get`s of the live view, each released: the `hold`, the snapshot, the
  `bound` message encoded, decoded and checked, the replicas built (two link hops).
- *wire bytes*: one whole message as its codec writes it (memory links add nothing).
- *encode / decode*: that message through the codec alone (`decode` without the schema check), averaged over 10,000
  runs (1,000 for snapshots and the 1 MiB call), the fastest of five such loops (one loop of a microsecond-sized
  message is at the mercy of the collector and the JIT).
- *heap per encode + decode*: heap bytes allocated per message while encoding and decoding it that many times,
  measured with `GCProfiler` (the growth plus what the collections freed); `ArrayBuffer` backing stores (the message
  bytes themselves) are outside the heap.
- *array buffer kept per encoded message*: the `process.memoryUsage().arrayBuffers` growth while 50 encoded copies of
  the message are kept, per message: the backing store a queued or held message keeps. Freed buffers are not reported
  reliably inside a loop, so allocation of temporary buffers is not measured. V8 keeps very small typed arrays on the
  heap, so the smallest binary messages show 0 B here.
- *commit to frame*: from the server's method call to the client's watch listener, averaged over 1,000 commits: the
  call and its transaction, the encodes, the hop, decode, check, apply, and the watch's delivery.
- *heap / array buffers retained per hold*: the heap and `arrayBuffers` growth of holding the 1,000-item view, after full collections, divided by the
  holds; both ends (the provider's member encoders and subscriptions, the consumer's member decoders and replicas,
  each its own decoded copy of the snapshot), median of seven trials.

| Case                                                                            | binary | text |
| ------------------------------------------------------------------------------- | --- | --- |
| notes list of 1,000 items: first hold to live (activation, one sample)          | 0.958 ms | 1.041 ms |
| notes list of 1,000 items: hold to live (two hops, mean of 100)                 | 0.666 ms | 0.686 ms |
| notes list of 1,000 items: snapshot: wire bytes                                 | 133.7 KiB | 133.7 KiB |
| notes list of 1,000 items: snapshot: encode / decode                            | 291.1 µs / 266.4 µs | 312.3 µs / 302.8 µs |
| notes list of 1,000 items: snapshot: heap per encode + decode                   | 441.5 KiB | 441.8 KiB |
| notes list of 1,000 items: snapshot: array buffer kept per encoded message      | 137.7 KiB | 133.7 KiB |
| 500 KB document: first hold to live (activation, one sample)                    | 1.461 ms | 1.555 ms |
| 500 KB document: hold to live (two hops, mean of 100)                           | 1.138 ms | 1.309 ms |
| 500 KB document: snapshot: wire bytes                                           | 496.5 KiB | 496.5 KiB |
| 500 KB document: snapshot: encode / decode                                      | 615.4 µs / 390.8 µs | 687.5 µs / 528.3 µs |
| 500 KB document: snapshot: heap per encode + decode                             | 1511.2 KiB | 1511.2 KiB |
| 500 KB document: snapshot: array buffer kept per encoded message                | 500.5 KiB | 496.5 KiB |
| one appended item: commit to frame                                              | 0.037 ms | 0.031 ms |
| one appended item: messages per commit, encodes per hold                        | 1, 1 | 1, 1 |
| one appended item: state message: wire bytes                                    | 165 B | 175 B |
| one appended item: state message: encode / decode                               | 1.4 µs / 1.4 µs | 0.9 µs / 1.1 µs |
| one appended item: state message: heap per encode + decode                      | 2607 B | 3034 B |
| one appended item: state message: array buffer kept per encoded message         | 165 B | 175 B |
| one changed field: commit to frame                                              | 0.036 ms | 0.031 ms |
| one changed field: messages per commit, encodes per hold                        | 1, 1 | 1, 1 |
| one changed field: state message: wire bytes                                    | 27 B | 38 B |
| one changed field: state message: encode / decode                               | 0.6 µs / 1.0 µs | 0.5 µs / 0.7 µs |
| one changed field: state message: heap per encode + decode                      | 2005 B | 2527 B |
| one changed field: state message: array buffer kept per encoded message         | 0 B | 38 B |
| one removed item: commit to frame                                               | 0.031 ms | 0.029 ms |
| one removed item: messages per commit, encodes per hold                         | 1, 1 | 1, 1 |
| one removed item: state message: wire bytes                                     | 23 B | 34 B |
| one removed item: state message: encode / decode                                | 0.6 µs / 1.0 µs | 0.5 µs / 0.7 µs |
| one removed item: state message: heap per encode + decode                       | 1704 B | 2575 B |
| one removed item: state message: array buffer kept per encoded message          | 0 B | 34 B |
| streamed reply, 2,000 appends: time per append                                  | 0.031 ms | 0.027 ms |
| streamed reply: bytes per append, total                                         | 23 B, 45.0 KiB | 34 B, 66.5 KiB |
| streamed token: wire bytes                                                      | 23 B | 34 B |
| streamed token: encode / decode                                                 | 0.5 µs / 1.0 µs | 0.5 µs / 0.6 µs |
| streamed token: heap per encode + decode                                        | 1696 B | 2527 B |
| streamed token: array buffer kept per encoded message                           | 0 B | 34 B |
| 1 hold(s) of 1,000 items: heap / array buffers retained per hold (both ends)    | 154.1 KiB / 47 B | 159.7 KiB / 21 B |
| 1 hold(s): messages per commit                                                  | 1 | 1 |
| 10 hold(s) of 1,000 items: heap / array buffers retained per hold (both ends)   | 175.2 KiB / 41 B | 175.2 KiB / 44 B |
| 10 hold(s): messages per commit                                                 | 1 | 1 |
| call, small argument: round trip                                                | 0.016 ms | 0.015 ms |
| call, small argument: call message: wire bytes                                  | 16 B | 23 B |
| call, small argument: call message: encode / decode                             | 0.6 µs / 0.4 µs | 0.5 µs / 0.6 µs |
| call, small argument: call message: heap per encode + decode                    | 1580 B | 1603 B |
| call, small argument: call message: array buffer kept per encoded message       | 0 B | 23 B |
| call, small argument: result message: wire bytes                                | 9 B | 14 B |
| call, small argument: result message: encode / decode                           | 0.4 µs / 0.3 µs | 0.5 µs / 0.5 µs |
| call, small argument: result message: heap per encode + decode                  | 1219 B | 1509 B |
| call, small argument: result message: array buffer kept per encoded message     | 0 B | 14 B |
| call, 1 MiB bytes argument: round trip                                          | 0.192 ms | 0.159 ms |
| call, 1 MiB bytes argument: call message: wire bytes                            | 1024.0 KiB | 1024.0 KiB |
| call, 1 MiB bytes argument: call message: encode / decode                       | 113.7 µs / 1.4 µs | 123.5 µs / 1.5 µs |
| call, 1 MiB bytes argument: call message: heap per encode + decode              | 3042 B | 3383 B |
| call, 1 MiB bytes argument: call message: array buffer kept per encoded message | 1028.0 KiB | 1024.0 KiB |

Observations:

- One message per commit and one encode per hold in every case (W1).
- The binary codec makes small messages 30-45 % smaller (a streamed token 23 B against 34 B; a changed field 27 B
  against 38 B) and allocates less heap per message; both are about 1 µs per small message each way. Binary decodes
  small messages a little slower than text: it makes one call per field (varints, strings, one `JSON.parse` per value)
  where text makes one `JSON.parse` of the whole tuple; the difference is under 1 µs per message and not worth
  optimizing. Snapshots are JSON in both and about the same size; binary decodes them faster, text encodes them a
  little faster (binary encodes the JSON text, then copies it into the message once).
- A binary message keeps a right-sized backing store (a 500 KB snapshot keeps about 500 KiB, not the 1.5 MB a buffer
  reserved for the worst-case UTF-8 length kept before the review).
- Kept backing stores of small binary messages (owner, 2026-10-22): a message is written into a 256-byte starting
  buffer, whose exact size is not known before the message is written, so in-place encoding does not right-size it.
  `finish` copies to an exact-size buffer when the spare room is at least 64 bytes and more than an eighth of the
  message. The appended-item state message (165 B) now keeps 165 B instead of 256 B, for about 0.2 µs more per encode
  (1.1 against 1.3-1.4 µs); messages up to about 100 B were copied before already (they show 0 B: V8 keeps such small
  arrays on the heap); large ones end within their 4 KiB of room and are not copied (the 1 MiB call keeps 1028 KiB).
- Large snapshots (owner's profiling request, 2026-10-22): the earlier "hold to live" gap (2.67 ms binary, 1.67 ms
  text) was one sample each; averaged over 200 holds both codecs took about 1.2 ms. The remaining real gap was the
  encode (886 against 718 µs): binary encoded the JSON text into its own buffer, then copied it into the message.
  Long strings (from 4,096 UTF-16 units) are now encoded straight into the message buffer behind a fixed five-byte
  length (a padded varint), and short ones (up to 42 units, a one-byte length) too: binary now encodes a 500 KB
  snapshot in 650 µs against text's 690 µs and holds it in 1.14 ms against 1.30 ms.
- A 1 MiB `bytes()` argument travels as 1 MiB plus a few bytes in both codecs (not base64's 1.33 MiB); its decode is a
  view (under 2 µs), its encode the one copy into the message.
- Encoding is not the bottleneck at these sizes; no CBOR.
- Each hold's replica is its own decoded copy (about 160-175 KiB for 1,000 entries); two references from one host are
  two holds by design.

## Slice 3b: surviving drops

Script and machine as for slice 3a (`test/bench/links.ts` now runs the 3b cases after the 3a ones, about 37 s).

New cases, both on the 1,000-item notes list view (133.7 KiB snapshot):

- *reconnect, N reference(s)*: N references held on the client (N holds of one provider object); the server's end
  of the link closes, the client sees the drop, then a new link is accepted and connected. *Time to all live*: from
  `connect` to every reference's `ref.state` being `live` again (the re-holds, N snapshots encoded, decoded and
  adopted as one frame `[["r", value]]` per member); the mean of 20 reconnects for one reference, 5 for 100. *Bytes*:
  what the new link carried both ways until then (the handshake included).
- *1,000 calls parked while down*: a small call (`ping`) made 1,000 times right after `connect`, before the re-hold is
  bound, so every call parks; time from `connect` to the last result (the re-hold, then 1,000 calls sent in order and
  answered), mean of 10; the order is checked at the provider and in the results.

| Case | binary | text |
| --- | --- | --- |
| reconnect, 1 reference of 1,000 items: time to all live (mean of 20) | 0.870 ms | 0.791 ms |
| reconnect, 1 reference of 1,000 items: bytes down / up | 133.7 KiB / 63 B | 133.8 KiB / 110 B |
| reconnect, 100 references of 1,000 items: time to all live (mean of 5) | 63.1 ms | 66.4 ms |
| reconnect, 100 references of 1,000 items: bytes down / up | 13370.5 KiB / 4718 B | 13371.1 KiB / 6736 B |
| 1,000 calls parked while down, flushed on reconnect: time to the last result | 14.9 ms | 13.8 ms |
| 1,000 parked calls: run in the order they were made | yes | yes |

Regression rows (the live paths of 3a, same run):

| Case | binary | text |
| --- | --- | --- |
| notes list of 1,000 items: hold to live (two hops, mean of 100) | 0.750 ms | 0.682 ms |
| 500 KB document: hold to live (two hops, mean of 100) | 1.134 ms | 1.308 ms |
| one appended item: commit to frame | 0.037 ms | 0.031 ms |
| one changed field: commit to frame | 0.036 ms | 0.029 ms |
| streamed reply, 2,000 appends: time per append | 0.031 ms | 0.027 ms |
| 1 hold of 1,000 items: heap / array buffers retained per hold (both ends) | 154.6 KiB / 47 B | 160.1 KiB / 21 B |
| 10 holds of 1,000 items: heap / array buffers retained per hold (both ends) | 175.1 KiB / 41 B | 175.4 KiB / 44 B |
| call, small argument: round trip | 0.016 ms | 0.014 ms |
| call, 1 MiB bytes argument: round trip | 0.192 ms | 0.191 ms |
| messages per commit, encodes per hold (every commit case) | 1, 1 | 1, 1 |

Observations:

- The live paths are unchanged within noise (3a: 0.67 / 0.69 ms per hold, 0.037 / 0.031 ms per appended item, 154.1 /
  159.7 KiB per hold); message sizes and encodes per commit are identical. A live reference's call checks its state
  once and makes no queue; `ref.state` is not made until read.
- A reconnect costs what the holds cost the first time: about 0.63 ms and one 133.7 KiB snapshot per reference of
  this size (100 references: 63 ms, 13 MiB). The consumer sends only the `hold`s (47 B each binary).
- 1,000 parked calls take about 14 ms to flush and answer, a little less than 1,000 sequential round trips (16 ms):
  they leave in one turn once the re-hold is bound. Each parked call keeps its arguments and one timer until sent.

## Slice 4a: links and relays

Script: `test/bench/relay.ts`, run from `packages/chord` with
`node --conditions=source --experimental-strip-types --expose-gc --no-flush-bytecode test/bench/relay.ts` (about
5 s; the forked workers are the same file run with the argument `worker`). Machine as for slice 3a. Binary codec
throughout. The topology is the one of slice 4a's example: a tab (a client host), a server with an address and a
route for `Session`, and per session a worker host whose `Store` (a local document) backs a remote `View` placed on
the session; the tab holds the view through the server, which relays (no part parsed).

What the numbers include:

- *call to frame*: the tab calls `stream` (one commit appending `" tok"` on the worker) and waits for both the result
  and its watch frame; mean of 1,000 after 100 warm-up calls. Through a relay that is four hops for the call and four
  for the frame and result (tab → server → worker → server → tab); the baseline is a tab directly on the worker.
  Slice 3a's *commit to frame* started at the provider, so these are not comparable with it.
- *bytes per commit*: bytes the server sent to the tab, and received from the worker, per commit (the `state`
  message and the call's result; acks and the call go the other way). From the worker the messages carry the tab
  link's origin (two bytes each).
- *first hold, `resolve` included*: a `tab.get` of a new session: the route resolves (an in-process worker host is
  created, connects, loads its facet with 1,000 entries and activates the view), the relayed hold, the 133.7 KiB
  snapshot through two links. The IPC row's first hold includes forking a Node process with strip-types (one sample).
- *the throttled tab*: the tab's end of its link delivers at 64 KiB/s (whole messages, in order; idle time banks no
  budget) in **virtual time**, 10 ms steps, so 60 s stalls run in well under a second. Per step: one token committed
  on the worker (100 tokens/s), the throttle's delivery, then every host's turn. Phases: the first snapshot of the
  500 KB view (8 s of virtual time at 64 KiB/s), 2 s of streaming, the pause (a stall: the tab receives nothing, so
  it acknowledges nothing; or the control: the same streaming without a stall), then 10 s more of streaming and
  until the tab's text equals the worker's. *Caught up after the stall*: virtual time from the end of the pause to
  the first step where the tab's view equals the worker's document; *bytes until then*: what the throttle delivered
  meanwhile. *Heap growth during the stall*: the
  process's heap after full collections at the end of the pause minus at its start (all hosts share one process;
  compare with the control row, which is the same streaming without a stall). *Commit at the worker*: the mean time
  of `store.stream` (the transaction, its flush: an encode when the window has room, a push into the pending queues
  when it is full), outside the pause and during it. *Longest message handling at the provider*: the longest single
  received message handled after the pause at the worker, the provider of the tab's state: its end of the tab link
  directly, of the route link relayed (the `ack` that sends the folded `state`).
- *calls*: tab B's sequential `ping`s through the relay, alone and while tab A has issued 10,000 `ping`s at once on
  the same session (two holds, two origins at the worker, each with its N = 256 running calls; the relay forwards at
  once).

| Topology (1,000 streamed tokens into the 1,000-item notes list view) | call to frame | bytes per commit: to the tab / from the worker |
| --- | --- | --- |
| memory tab, in-process worker (memory links) | 0.053 ms | 27 B / 29 B |
| memory tab, forked worker (IPC) | 0.097 ms | 27 B / 29 B |
| first hold to live, the fork included (one sample) | 240 ms | - |
| loopback WebSocket tab (`ws` serving, Node's `WebSocket`), forked worker (IPC) | 0.148 ms | 27 B / 29 B |
| no relay: memory tab on the worker (baseline) | 0.034 ms | 27 B / - |

| Hold to live, the 1,000-item notes list view (133.7 KiB snapshot) | time |
| --- | --- |
| first hold, `resolve` of an in-process worker included (mean of 20) | 1.375 ms |
| hold of a resolved session through the relay (four hops, mean of 100) | 0.763 ms |
| no relay: hold on the worker (two hops, mean of 100, baseline) | 0.703 ms |

| Throttled tab (64 KiB/s), 100 tokens/s into the 500 KB view | caught up after the pause | bytes to the tab until then | heap growth during the pause | commit at the worker, outside / during the pause | longest message handling at the worker after the pause |
| --- | --- | --- | --- | --- | --- |
| direct, 1 s stall | 0.02 s | 485 B | 28.0 KiB | 0.018 ms / 0.030 ms | 0.169 ms |
| direct, 10 s stall | 0.08 s | 4147 B | 134.2 KiB | 0.029 ms / 0.023 ms | 0.053 ms |
| direct, 60 s stall | 0.38 s | 23.7 KiB | 392.2 KiB | 0.028 ms / 0.017 ms | 0.138 ms |
| direct, 60 s without a stall (control) | 0.01 s | 23 B | 482.7 KiB | 0.025 ms / 0.017 ms | 0.005 ms |
| relayed, 1 s stall | 0.02 s | 485 B | 7.5 KiB | 0.025 ms / 0.025 ms | 0.057 ms |
| relayed, 10 s stall | 0.08 s | 4147 B | -25.3 KiB | 0.030 ms / 0.015 ms | 0.059 ms |
| relayed, 60 s stall | 0.38 s | 23.7 KiB | 513.5 KiB | 0.026 ms / 0.015 ms | 0.146 ms |
| relayed, 60 s without a stall (control) | 0.01 s | 23 B | 257.1 KiB | 0.023 ms / 0.021 ms | 0.003 ms |

| Calls through the relay (in-process worker, memory links) | p50 | p95 | max | calls |
| --- | --- | --- | --- | --- |
| tab B alone | 0.012 ms | 0.018 ms | 0.600 ms | 1,000 |
| tab B while tab A has 10,000 calls in flight or queued | 4.851 ms | 10.701 ms | 10.708 ms | 27 |
| tab A: 10,000 calls at once, until the last result | 657 ms | - | - | 10,000 |

Observations:

- A relay hop costs about 0.019 ms per commit-to-frame on memory links (0.053 against 0.034 ms for call, commit, frame
  and result) and adds no bytes to the tab: the server forwards the worker's message with the origin taken off (ids
  unchanged, parts copied once); the origin costs two bytes per message on the route link. IPC to a forked worker adds about 0.04 ms, a loopback WebSocket to the tab another 0.05 ms.
- Hold to live through the relay is within 9% of a direct hold (0.763 against 0.703 ms): the relay never parses the
  133.7 KiB snapshot. A first hold that resolves an in-process worker (create, connect, load, activate) takes 1.4 ms;
  forking a strip-types Node process takes about 240 ms, which is the app's to hide (start workers ahead).
- Directly, the provider's pending queue folds a stall of any length into one append (24 KiB of text after 60 s,
  sent in 0.38 s at 64 KiB/s); committing while the window is full costs no more than committing with room (about
  0.02 ms), and the folded message is encoded in under 0.2 ms. The stall adds no heap beyond the control's, which is
  the streamed text itself on the worker and the tab.
- Through the relay a stall now costs what it costs directly (decision "Relay flow control per origin"): the worker
  keeps the tab origin's window and folds its commits into its pending queues, the relay forwards and acknowledges
  per message. Before this rework the relay ran the tab's window itself and recovered with `reset`: every stall, even
  1 s, cost three full snapshots (about 1.5 MiB) and about 24 s to catch up under sustained streaming.
- Tab B's calls are their own origin at the worker, with their own N, but B's call still waits behind the up to 256
  calls of A running there (one worker, one event loop): about 4.9 ms median, 11 ms p95, against 0.01 ms alone. A's
  10,000 calls take 0.07 ms each (its window of 256 refills one reply round trip through the relay at a time).
- A first run of this script found about 350 B retained per call or commit: `AbortSignal.any` on Node 24.4.1 keeps
  cleanup entries per call while its sources live (nodejs/node#62367, fixed in 24.16.0). Calls and gets now link
  their signals only until they settle (`withLinkedAbortSignal`); the numbers above are after that fix (heap during a
  60 s stall: 2.3 MiB before, 0.4 MiB after).

## Slice 4b: authority and housekeeping

Script: `test/bench/compression.ts`, run from `packages/chord` with
`node --conditions=source --experimental-strip-types --expose-gc test/bench/compression.ts` (about 5 s). Node
24.4.1, Intel Core i9-13900, one process.

Payloads: the 500 KB document of slice 3a (500 entries `{ id, text, author, at }` of 960 characters), but with
prose-like text (words from a small vocabulary in a fixed pseudo-random order, some with numbers: it compresses about
3.6x at level 1, as conversation JSON does; the `"x".repeat` texts of the earlier benchmarks would compress about
100x and say nothing), and a 1 MiB string as a call's result (a file export). Compression is option (b) as built:
`nodeCompression` (zlib's raw deflate at level 1) at the origin; the owner inflates with `nodeCompression`
(synchronous, a Node client) or `DecompressionStream` (asynchronous, a browser).

- *deflate at the origin / inflate*: one part through the adapter alone, mean of 20, the fastest of three loops.
- *end to end*: a server and a client host on a memory link (binary codec); *hold to live* is a further `get` of the
  live view (snapshot encoded, deflated, sent, inflated, parsed, replicas built), *call to result* a call returning
  the 1 MiB string; *bytes received* is the one message as the client's link delivered it.

| Payload | JSON | deflated (level 1) | deflate at the origin | inflate, sync (`nodeCompression`) | inflate, async (`DecompressionStream`) |
| --- | --- | --- | --- | --- | --- |
| 500 KB snapshot | 494.9 KiB | 137.4 KiB | 3.308 ms | 0.915 ms | 1.400 ms |
| 1 MiB result | 1024.0 KiB | 286.1 KiB | 6.856 ms | 1.757 ms | 3.113 ms |

| End to end over a memory link (binary codec) | snapshot: bytes received | hold to live (mean of 20) | 1 MiB result: bytes received | call to result (mean of 20) |
| --- | --- | --- | --- | --- |
| uncompressed | 494.9 KiB | 1.197 ms | 1024.0 KiB | 1.939 ms |
| deflated, inflated synchronously (Node client) | 137.5 KiB | 5.632 ms | 286.1 KiB | 10.868 ms |
| deflated, inflated asynchronously (browser client) | 137.5 KiB | 6.356 ms | 286.1 KiB | 12.198 ms |

Rerun after the review fixes (inflate only after admission by the part's owner, a tagged adapter result, byte counts
for the threshold): the same within noise (the asynchronous inflate of the 500 KB part varies between 1.4 and 2.0 ms
from run to run).

Observations:

- Level 1 cuts prose-like JSON to 28% (494.9 to 137.4 KiB, 1 MiB to 286 KiB) at about 6.7 ms per MiB deflated at the
  origin and 1.8 ms per MiB inflated synchronously; `DecompressionStream` takes about twice as long as zlib's
  synchronous inflate (3.1 against 1.8 ms per MiB) and adds its own turns, which the in-order holding of the link's
  later messages absorbs.
- On a memory link (no transport time) compression only costs: hold to live 1.2 → 5.6 ms, the 1 MiB call 2.0 →
  10.9 ms. It pays where bytes take time: at 10 MB/s a 500 KB snapshot takes about 50 ms uncompressed and 14 ms
  compressed (plus 4.3 ms of deflate and inflate); at 1 MB/s (a phone) 500 ms against 140 ms. On IPC to a worker
  (gigabytes per second) it does not pay for itself on that hop: it pays on the tab's WebSocket, where the relay
  forwards the worker's deflated part as it is (a test counts no inflate at the relay).
- Parts at or below 16 KiB (UTF-8 bytes) are never compressed (a state change, most call arguments), nor is a part
  that deflating does not make smaller (sent as the bytes encoded for the attempt, never encoded twice), nor hold
  params, nor call arguments sent up a parent link: the cost per message of the slices 3a-4a benchmarks is unchanged. The binary codec's part prefix (length doubled, plus one when deflated) costs
  a byte more for parts between 64 and 127 bytes.

## Slice 6a: the store

`test/bench/store.ts` (run by hand: `node --conditions=source --experimental-strip-types --expose-gc
test/bench/store.ts` from `packages/chord`): Node 24.4.1, `chord/sqlite/node` on a fresh SQLite file per burst
for both sides (the same pragmas and file system), 7 bursts of 1,000 commits after a warm-up burst; per commit, the
median and p95 of single commits and the burst's mean.

The gate (decision "The commit-step benchmark"): the store without outbox no slower than Durable's `SqliteStorage`.

| Case | Durable | Chord store | Chord store + outbox |
| --- | --- | --- | --- |
| (a) one document delta per commit (step level) | 23.7 / 31.4 / 32.9 µs | 13.4 / 18.7 / 20.9 µs | 16.6 / 29.2 / 26.7 µs |
| (b) one table `put` (Durable: one entry append) | 19.3 / 27.1 / 29.5 µs | 13.2 / 23.6 / 20.6 µs | 17.5 / 28.1 / 26.3 µs |
| (c) whole transactions back to back, no watch (Durable `Session`, Chord host) | 35.0 / 61.1 / 44.4 µs | 18.1 / 27.2 / 25.7 µs | 20.3 / 38.8 / 30.7 µs |
| (c) the same with a watched document | 34.1 / 55.4 / 42.4 µs | 20.6 / 26.3 / 27.1 µs | 20.2 / 39.0 / 29.9 µs |
| (d) one in-memory document per transaction (no store) | | 2.5 / 2.9 / 2.7 µs | |
| (d) the same, watched | | 2.6 / 4.4 / 2.7 µs | |

Every gate case passes. The outbox adds 3-5 µs per commit (one `INSERT` of the commit's writes as JSON). The heap after
GC at the end of the whole script is about 3 MiB above its start (the modules and statement caches loaded on the way).

In-memory transactions against HEAD (before slice 6a), after the second fix round (`Transaction.draft` returns its
draft's promise as it is: an in-memory `change` settles in 5 microtask turns, HEAD 6, a test guards it): one `change`
per transaction through a host, 15 bursts of 1,000 per process with a timer around each `change`, HEAD's source
extracted beside this checkout, the same script on both, alternating processes pinned to one CPU (`taskset -c 4`),
three runs; median / p95 / burst mean:

| Case | HEAD | now |
| --- | --- | --- |
| unwatched document | 2.52-2.55 / 4.96-5.02 / 5.41-5.44 µs | 2.56-2.60 / 5.02-5.06 / 5.69-5.71 µs |
| watched document | 2.96-3.07 / 6.44-6.54 / 6.81-6.90 µs | 2.96-3.01 / 6.35-6.42 / 6.88-6.95 µs |
| watched derive through a reference | 3.14-3.29 / 6.77-6.93 / 8.38-8.50 µs | 3.06-3.08 / 6.49-6.53 / 7.52-7.54 µs |

What the differences are (the second review's measurements, Opus):

- The change path itself is at HEAD's level or below. Without the per-operation timer, a tight loop of 200,000 changes
  costs 3.67-3.69 µs against HEAD's 3.70-3.78 µs (and the loop of the timed harness 4.85-5.06 µs against
  5.15-5.24 µs). Allocation per change is lower (7,703 B against 8,035 B, measured with a semi-space of 128 MB so no
  scavenge lands in a burst), and so are the collections (40 hosts of 2,000 changes: 34 scavenges against 38, 2
  mark-compacts on both).
- The median difference of the timed harness (+1-2% here, up to +3-7% elsewhere) comes from the per-operation timer:
  it stays with zero collections in the bursts and disappears without the timer, so it is harness-sensitive (code
  layout, inline caches), not work in the change path.
- The burst means differ by where a mark-compact lands: the worst burst per process coincides with a mark-compact over
  a larger old space (67 MB against 45 MB before the collection, about 18 MB after on both; a pause of 5.2-7.1 ms
  against 3.0-3.7 ms), which is heap-growth timing, not extra garbage. Host setup is about 3% above HEAD (21.9-23.2 µs
  against 21.1-21.9 µs per host, create, load and get; close equal), which the burst means include too.

Calls and references (`taskset -c 4`, five alternating pairs of processes; one host, 21 bursts of 3,000 operations
after 3 warm-up bursts, a timer around each; reads: 200,000 per burst, burst means). Every call admits its handler to
the drain and its cleanup (call count, `ctx.get` references) in one map entry with one reaction: 19 promises per call
against HEAD's 20, a test guards it. A reference's state members are its object's member sources (one per object and
member, re-bound when a new attempt goes live): a watch through a reference gets the member's frame passed on as it is
(one call more per frame), a read goes through one getter more.

| Case | HEAD | now |
| --- | --- | --- |
| local call: median / p95 / burst median / burst p95 | 1.49-1.51 / 1.93-1.99 / 1.64-1.67 / 2.51-2.75 µs | 1.47-1.48 / 1.93-1.96 / 1.59-1.61 / 2.40-2.47 µs |
| `change` under a watch through a reference, derive member: median / p95; frames per second | 2.80-2.92 / 4.64-4.80 µs; 268,000-282,000 | 2.76-2.87 / 4.75-4.84 µs; 278,000-288,000 |
| the same, document member | 2.68-2.79 / 4.58-4.79 µs; 285,000-306,000 | 2.67-2.76 / 4.57-4.79 µs; 285,000-306,000 |
| `ref.member.value`, derive member | 9.24-10.82 ns | 8.53-8.57 ns |
| `ref.member.value`, document member | 10.02-10.10 ns | 10.30-10.32 ns |

Calls are 1-3% faster than HEAD (bursts' p95 10% lower), watches through a reference at HEAD's level (p95 +1-2% for a
derive member, more frames per second), a derive member's read faster; a document member's read costs 0.25 ns more
(the member source's getter in front of the slot's).

A local document member re-exposed by a remote object and held over a memory link (one `change` and its state message
per operation; Astra's third review harness, `taskset -c 4`, alternating pairs, 41 bursts of 10,000 after 3 warm-up
bursts): a member source passes its subscribers (holds, member sources re-exposing it) on to the member it follows, so
their frames take no extra hop. Burst median 7.80-8.38 µs against HEAD's 7.82-8.35 µs, burst p95 8.84-9.44 against
9.52-10.06 µs, median per operation 6.76-7.34 against 6.82-7.29 µs (before the pass-through, one run: 8.51 / 13.05 µs
against 7.99 / 10.36 µs). Host setup (+2-4%) and a document member's read through a reference (+0.25 ns) are accepted
as they are.

After Delta's tracker stopped allocating a `WeakRef` per change (pi a92283056, merged as 95ec93a08), against HEAD
95ec93a08 (which has that change too) extracted at a path as long as this checkout's (44 characters). Sol's tight
harness without a per-operation timer (`taskset -c 4`, five alternating pairs of processes, 31 bursts of 10,000 after
3 warm-up bursts; medians of the burst medians, ranges in parentheses):

| Case | HEAD | now |
| --- | --- | --- |
| unwatched `change` | 1.96 µs | 1.96 µs (0.0%) |
| `change` under a watch of the document | 2.24 µs | 2.19 µs (-2.1%) |
| `change` under a watch through a reference | 2.23 µs | 2.21 µs (-0.8%) |
| `change` under a watch of a derive through a reference | 2.33 µs | 2.26 µs (-2.9%) |
| local call | 1.36 µs | 1.33 µs (-1.9%) |
| a document member forwarded into a remote object, held over a memory link | 6.60 µs (6.54-6.63) | 6.52 µs (6.48-6.59) (-1.2%) |
| the same, yielding a macrotask every 1,000 operations | 6.67 µs (6.57-7.02) | 6.54 µs (6.42-6.79) (-1.9%) |

Collections over one forwarded-link run (`--trace-gc-nvp`, 340,000 operations, two processes each; scavenges and
promotion were the same in both):

| Run | Promoted | Scavenges | Mark-compacts | GC pauses |
| --- | --- | --- | --- | --- |
| HEAD | 6 MB | 158 | 2 | 154 ms |
| now | 7 MB | 148 | 2 | 147-148 ms |
| HEAD, yielding every 1,000 | 6 MB | 186 | 2-3 | 149-162 ms |
| now, yielding every 1,000 | 7 MB | 178 | 2-3 | 145-149 ms |

History: the fifth fix round's measurement, before the Delta change (failure calls once per episode, watches on
failed sources, keyed pins still loading). Sol's tight harness without a per-operation timer (`taskset -c 4`, five
alternating pairs of processes, 31 bursts of 10,000 after 3 warm-up bursts; burst medians, HEAD's source at
`/tmp/chord-head4`, this checkout at its own path):

| Case | HEAD | now |
| --- | --- | --- |
| unwatched `change` | 2.91 µs | 2.95 µs (+1.5%) |
| `change` under a watch of the document | 3.14 µs | 3.10 µs (-1.4%) |
| `change` under a watch through a reference | 3.10 µs | 3.08 µs (-0.4%) |
| `change` under a watch of a derive through a reference | 3.21 µs | 3.26 µs (+1.6%) |
| local call | 1.37 µs | 1.35 µs (-2.0%) |
| a document member forwarded into a remote object, held over a memory link | 7.80 µs | 8.32 µs (+6.6%) |
| the same, `--no-allocation-site-pretenuring` | 8.12 µs | 8.04 µs (-1.0%) |
| the same, yielding a macrotask every 1,000 operations | 7.17 µs | 8.61 µs (+20%) |
| the same, yielding, `--no-allocation-site-pretenuring` | 7.21 µs | 7.52 µs (+4.2%) |

Allocation per operation, with a fixed semi-space of 256 MB so no scavenge lands in the measured 20,000 operations, is
below HEAD's in every case: 6,942 B against 7,317 B unwatched, 8,383-8,393 B against 8,764 B watched, 8,935-8,939 B
against 9,338 B for a derive, 8,405-8,413 B against 8,764 B through a reference, 2,885 B against 3,089 B over the
link. What stays after the link drains and a GC is equal (18.9 against 19.0 B per operation).

The forwarded-link gap is not work or retention in 6a's code. It is a V8 decision that depends on heap layout:

- With huge semi-spaces (no scavenges) the two take the same time (10.01 against 10.00 µs). Without pretenuring (the
  flag above) they are equal too.
- An identical copy of this checkout's source runs at HEAD's level (7.1 µs, 7 MB promoted over the run) when its path
  is at most 40 characters long (`/tmp/wexp/packages/chord/src`). From 44 characters on it flips: 46 MB promoted, 4
  mark-compacts instead of 2, about 9 µs. The repository's own path is 44 characters. HEAD's source does not flip at
  any tested path length (28 to 62 characters).
- `--trace-deopt` shows the flip: V8 marks the allocation site of the delta tracker's per-change overlay context
  (`createContext`, inlined into `beginChange` and `Transaction.#begin`) as tenured. From then on every change's context
  is allocated in old space and dies there.
- The contexts survive scavenges because each change registers its context as a `WeakRef` target
  (`TrackerImpl.#register`). A `WeakRef` keeps its target alive until the current job ends, and scavenges do not
  clear it. So a site that allocates one context per change shows a high survival rate.
- Heap snapshots taken during and after the run are equal between the two trees, and no 6a object outlives its
  change.
- pi a92283056 ("Delta's tracker holds its one open change without a WeakRef") removed the cause: the numbers above
  it show the forwarded link at HEAD's level with 6-7 MB promoted and 2 mark-compacts on both.

A retirement under a diamond of derives (`test/bench/derives.ts`: 40 derives in 13 layers of two derives joined
by a third, 2^13 paths from top to bottom, the bottom watched; one step retires and recreates the document in one
transaction): 9.8 µs median, 17.7 µs p95 per step with one visit per derive per batch; 349 µs without the visited set
(one visit per path).

Binary `state` messages (`test/bench/links.ts`, against HEAD, alternating, pinned): an entry without retirements
costs no extra byte (165 / 27 / 23 B for one appended item, one changed field, one removed item, as at HEAD); encode
and decode are at HEAD's level (one changed field, 200,000 runs, best of 9: encode 1,167-1,203 ns against
1,172-1,275 ns, decode 692 against 685-705 ns); heap per encode and decode 1,592 / 1,631 / 1,363 B against 1,684 /
1,726 / 1,355 B; commit to frame within HEAD's range (0.112-0.166 ms against 0.111-0.164 ms). After the second fix
round (`taskset -c 4`, two runs each): commit to frame 0.086-0.087 / 0.097-0.099 / 0.065 ms against 0.084-0.089 /
0.098-0.099 / 0.064 ms, a streamed append 0.053 ms against 0.051-0.053 ms, the same bytes and heap.

Other costs (one run each):

| Cost | Result |
| --- | --- |
| 100 commits submitted at once: time waiting in the queue against the step itself | median wait 956 µs, step 11.3 µs |
| a query page of 100 rows in an index's order (10,000 rows, cursors) | 113 µs per page |
| one `updateWhere` over 10,000 rows | one step of 10.6 ms (every owner's commits wait behind it) |
| `put` with 10-character text cells / 10,000-character cells (2,000 rows, one commit) | 2.4 / 58.4 µs per row |
| a `rows` migration of 10,000 rows (100 chunks; `taskset -c 4`) | 69-71 ms in all, 7.0 µs per row; chunk commits: first 0.34 ms, last 0.21 ms, median 0.22 ms |

Observations:

- The commit step is cheaper than Durable's per commit: Chord keeps no generic entry log beside the documents engine
  and its tables, and serializes writes before the queue (rule 8).
- Between chunks a migration yields one macrotask without the 1 ms clamp of `setTimeout(0)`: `setImmediate` where the
  runtime has it, else a `MessageChannel` message (Workers, browsers). The same 10,000-row migration takes 191 ms with
  `setTimeout(0)` (99 clamped yields) and 100 ms with messages in Node (0.27 ms per yield there, against 13 µs for
  `setImmediate`).
- Late migration chunks cost what early ones do (paging forward by the last key keeps each chunk's read bounded); the
  spec's estimate of about 15 µs per migrated row holds with room.
- A bulk write's step is the one place a single commit holds every owner's commits for milliseconds; the guide says so.

## Slice 6b: Durable on the store, persisted jobs (2026-10-28)

Node 24.4.1, one CPU (`taskset -c 6`), SQLite files in `tmpdir()`. HEAD is `b2fcfee08`, extracted at a path of the same
length (`/home/badlogic/pi-6h`); runs alternate HEAD and the build.

**Durable's storage benchmark** (`packages/durable/test/storage.bench.ts`, `TIMING_SCALE`), `StoreStorage` (outbox off)
against `SqliteStorage` in the same process, mean ms per operation over three runs (p75 where the mean is one outlier):

| Case | SqliteStorage | StoreStorage | |
| --- | --- | --- | --- |
| exact entry lookup | 0.0030 | 0.0030 | 0% |
| entry page scan (100) | 0.0942 | 0.0940 | 0% |
| filtered task scan (50) | 0.0206 (p75 0.0200) | 0.0220 (p75 0.0207) | +7% mean, +3% p75 |
| exact document address among many | 0.0037 | 0.0037 | 0% |
| document replay tail (0) | 0.0089 (p75 0.0084) | 0.0092 (p75 0.0085) | +3% mean, +1% p75 |
| document replay tail (16 / 128 / 1024) | 0.0300 / 0.1726 / 1.224 | 0.0270 / 0.1522 / 1.135 | -10% / -12% / -7% |
| ancient / recent historical read | 0.1681 / 0.1611 | 0.1541 / 0.1513 | -8% / -6% |
| fork-depth history scan (100) | 0.1177 (p75 0.1156) | 0.1208 (p75 0.1159) | +3% mean, 0% p75 |
| fork-depth head lookup | 0.0361 | 0.0332 | -8% |
| commit one entry (20 samples) | 0.0439 (p75 0.0416) | 0.0601 (p75 0.0373) | +37% mean, -10% p75 |
| commit 100 entries | 0.743 | 0.620 | -17% |
| commit mixed entry/task/submission/document | 0.195 | 0.187 | -4% |
| reopen and first exact read | 0.294 | 0.443 | +51% |

Warm micro-benchmarks behind the same cases (each read 20,000 times; commits 10,000 after 2,000 warm-up): page scan
91.2 vs 90.6 µs, task scan 19.9 vs 20.1 µs, fork-depth scan 114.1 vs 114.9 µs, head lookup 35.3 vs 32.9 µs, document
address 3.57 vs 3.68 µs, replay tail (0) 8.41 vs 8.44 µs; one entry per commit 29.6 vs 27.8 µs mean, 18.4 vs 17.1 µs
median. What it took, beyond the first build's compiled reads, point lookups without a bound `LIMIT`, version columns
selected only past version 1 and the counting read guard:

- **Reads select only the record.** A scan selected an entry's `commit_seq` too (only `entry(id)` needs it): 7% of a
  page scan.
- **No index for head markers on every entry.** `entries.by_head (conversation_id, has_head, id)` cost about 5.5 µs per
  commit (a raw insert: 39.7 vs 45.2 µs); `SqliteStorage` has a partial index (`WHERE head IS NOT NULL`), which the
  table vocabulary does not have. The head markers are an `entry_heads` table instead, written only with an entry that
  has one: a commit without one writes no second index, and a head lookup reads the newest head's id, then the entry.
- **A document record is one JSON text.** `meta` keeps the whole Durable record, its creation seq included; a read
  selects `meta` (and `retired_at` only at a point).
- **A store already at the newest schema opens with one read** (schema version, encoding and metadata row), without
  the migrations' write transaction: 84 → 71 µs on a fresh connection.

Commit one entry: the mean is one sample (Maglev compiling the commit path on the first fixtures: 130 and 386 µs at
fixtures 25 and 30 of the first store round of a 60-fixture replay, none in the second round, no GC or deopt traced);
the median and p75 are lower than `SqliteStorage`'s. Reopen: a fresh connection on a copied file, measured in parts
(`openNodeSqliteDatabase` is the same for both): `SqliteStorage.open` 42-60 µs; `openStore` 63-71 µs (the schema read,
the catalog with its JSON parse) plus `StoreStorage.open` 75 µs (declaring six tables: their SQL rendered, claims; the
catalog check of the table preparation; `max(record_ids.id)` for the allocator, as §2.1 asks; compiling the point
reads), first read +3 µs: about 0.1-0.15 ms once per open, cold code, not on any hot path.

**Statements per commit** (cost guard in `packages/durable/test/store-storage.test.ts`): an entry append and a document
delta take 4 each (`SqliteStorage`: 5 and about 7).

**Memory** (`packages/durable/test/storage-memory.ts`): heap after seeding 0.16 → 0.30 MiB (1k), 0.17 → 0.32 MiB (10k):
a fixed cost of the store (catalog, compiled statements, claims, the store's code), the same at both scales; heap after
reads 0.13 → 0.16-0.18 MiB. Disk 0.61 → 0.58 MiB (1k), 4.34 → 4.38 MiB (10k).

**Chord's commit gate** (`test/bench/store.ts`), HEAD → build, two alternating runs each, medians:

| Case | HEAD | build |
| --- | --- | --- |
| (a) one document delta per commit | 13.6-13.7 µs | 13.8-14.0 µs (+2%) |
| (b) one table put per commit | 12.8-13.3 µs | 13.0-13.2 µs |
| (c) whole transactions (no watch / watched) | 17.2-17.3 / 17.1-17.2 µs | 17.4-17.7 / 17.2-17.7 µs (+2%) |
| (d) one in-memory document (median / burst) | 2.1 / 2.9-3.0 µs | 2.1 / 4.9 µs |
| heap after GC | 2940 KiB | 2996 KiB |

The revisions index is a partial index on bases (`(document_id, seq) WHERE kind = 'base'`): a delta writes no index
entry (the first build's `(document_id, kind, seq)` cost (a) 15%). (d)'s burst is not the in-memory path: run alone
(only section (d), three alternating runs) HEAD gives 4.9-5.1 µs and the build 4.9-5.0 µs per commit, and 40 bursts of
1,000 in a fresh process 2.17 vs 2.18-2.38 µs; in the full gate, HEAD's in-memory path runs warm from the persisted
sections before it, the build's does not share as much of their code (`StoredChange`'s variants).

**Durable's conversation view benchmark** (`test/conversation-view-bench.ts`, `PI_DURABLE_BENCH_STORAGE`), two runs
each, `SqliteStorage` → `StoreStorage`: append one entry per commit 56.1-57.2 → 56.2-57.0 µs with one watch, 61.0-62.1
→ 62.7-63.1 µs with four (+2%); bursts of 50 884-888 → 891 µs; `pi.live` only 62.7-63.0 → 65.1-66.6 µs (+4-6%); a
long-lived watch over 20,000 appends 0.83-0.85 → 0.84-0.85 s CPU; heaps 21.5 → 21.7 MiB.

**Fix round 1** (2026-10-28, after the build reviews): `StoreStorage`'s reads take one promise besides the store's guard
(no `#call` wrapper; `close` waits for its commits, a read changes nothing), their request errors in a tagged result.
Warm micro-benchmark (20,000 runs, two runs each, `SqliteStorage` → `StoreStorage`): filtered task scan 19.8 → 19.8-20.1
µs, `entry(conversation, id)` over the fork chain 23.1 → 21.9-22.3 µs. `storage.bench.ts` (two runs): task scan mean
0.0207 → 0.0217-0.0218 ms (p75 0.0200-0.0203 → 0.0204-0.0206), fork-depth scan 0.1177-0.1188 → 0.1210-0.1242 (p75
0.1154-0.1167 → 0.1160-0.1193), the rest as above.
`conversation-view-bench` "resume 20 back", three runs: CPU 4.23-4.47 → 4.50-5.14 ms for a 3 ms scenario (one sample
each; the head lookup and scans under it are at parity or faster in the micro-benchmark). The persisted-job fixes
(one invocation per call of `run`, held state folded in a `PendingOps`): start 55.5 → 55.2 µs, immediate state change
21.3 → 21.2 µs, deferred 3.2 → 3.5 µs (the fold), in memory unchanged.

**Persisted jobs** (`test/bench/jobs.ts`, 7 bursts of 500, medians): a start (resolved after its commit) 8.4 µs in
memory, 55.5 µs persisted (two commits: the record and state created, then the reservation); a state change inside
`run` 2.7 µs in memory, 21.3 µs persisted (one delta commit, as the gate's (c)), 3.2 µs deferred (stored with the
outcome).

## Slice 8: registries and `host.root` (2026-10-28)

Node 24.4.1, one CPU (`taskset -c 6`), runs alternating. HEAD is `391e83fb1`, extracted at a path of the same length
(`/home/badlogic/pi-h8`); the build was measured in the worktree and, where the worktree itself skewed a result (below),
in an extract of the same sources at `/home/badlogic/pi-x8`.

**Paths under every object** (`test/bench/calls.ts`, new: runs on HEAD as it is), median per operation over nine
bursts, heap allocated per operation, three alternating runs each, HEAD → build:

| Case | HEAD | build |
| --- | --- | --- |
| local method call (its ctx) | 2.80-2.81 µs, 6,894 B | 2.81-2.83 µs, 6,894 B |
| commit through a watched derive (`batch.compute`) | 10.34-10.43 µs, 15,312 B | 10.46-10.51 µs, 15,310 B |
| activation churn: get, live, release (an object with params) | 57.5-59.3 µs, 43,696-43,717 B | 58.1-58.9 µs, 43,782-43,787 B |
| retained per live object (10,000 kept) | 6,586 B | 6,602 B |

The attempt keeps its registry reads, contributions, wake signals and writables in one record made by the first such
declaration, and iterates nothing when there is none: the first build allocated 1,020 B more per activation (six
arrays per attempt, an array iterator per `for … of` over an empty list, a copy from `splice`) and retained 72 B more
per live object; now +70 B allocated and +16 B retained (one field on the attempt, one on the object).

**Existing benchmarks**, HEAD → build: the derive diamond (`derives.ts`, three runs) 9.4-9.8 → 9.5-9.9 µs median; its
pooled p95 16.5-17.1 → 18.4-20.8 µs comes from the run in which V8 tiers the commit path up (per run, after it: HEAD
10.7-11.3 µs, build 10.1-11.3 µs; the first measured runs 15.0-25.6 µs on either side, in another run each), the same
with HEAD's `batch.ts` and `derive.ts` in the build. The store gate (`store.ts`, three runs): every median within
0.4 µs (Chord store 13.0-13.9 → 13.0-14.2 µs, Chord host 17.3-18.2 → 17.3-17.8 µs, in-memory document 2.1 → 2.2 µs),
heap 3,498 → 3,144 KiB. Jobs (`jobs.ts`): start 8.4 → 8.5 µs in memory, 55.4 → 56.2 µs persisted; state change 2.7 →
2.7, 21.3 → 21.8, 3.4 → 3.5 µs. Links (`links.ts`, three runs): wire sizes, encodes, decodes and heap per message
unchanged; its round trips are one cold burst each and vary as much between HEAD runs (commit to frame, text codec,
0.055-0.076 ms). A warmed remote call (2,000 calls per burst, nine bursts, a memory link): binary 7.16-7.24 → 7.17-7.29
µs, text 7.66-7.72 → 7.70-7.83 µs in the extracts; the worktree itself runs the same sources at 7.8-7.9 µs (binary),
an effect of the tree, not the code.

**Registries and writables** (`test/bench/registries.ts`, new), median over nine bursts: `writable.set` delivered
to one watch 0.81-0.91 µs (2.9 KB allocated: the batch and the watch's call); a set of the same value 0.008 µs, 0 B
(one comparison: its batch work is a method of its own, so `set` allocates no closure context); one of 10 contributions
changed while the registry is watched 0.74-0.77 µs, of 100 1.52-1.59 µs (the table built again over every entry, one
compose per set: the counted `chord.registry.composes` is 1.00 per set).

**Fix round 1** (2026-10-28), HEAD extract → build extract (`/home/badlogic/pi-x8`), CPU 6. `calls.ts`, two runs: local
method call 2.80 → 2.80-2.81 µs, 6,894 B both; commit through a watched derive 10.51-10.65 → 10.72 µs; activation churn
57.9-59.0 → 59.3-60.0 µs, 43,714 → 43,769-43,787 B. The derive diamond (five runs): median 9.4-9.8 → 9.5 µs, pooled p95
16.4-16.7 → 19.0-19.2 µs. Per run, both have one slow run while V8 tiers the commit path up (HEAD its second, median/p95
15.5/22.6-22.9 µs; the build its first, 16.4/26.7-27.2 µs) and equal runs after it (HEAD 8.8-9.6/9.6-11.2 µs, build
8.9-9.8/9.7-10.6 µs). `batch.compute` is not the cause: HEAD's `batch.ts` and `derive.ts` in the build give the same
p95, and swapping host files moves it without a pattern (code layout, not work on the path). `registries.ts`:
`writable.set` 0.87 µs, the same value 0.011-0.016 µs and 0 B (the seal check now comes first: a set of an ended
attempt's writable throws whatever its value); one of 10 contributions set 0.71-0.78 µs, of 100 1.43-1.61 µs (one run
in six 3.4 µs on either variant tried: JIT).

## Slice 7a: the dependency model (2026-10-29)

Node 24.4.1, one CPU (`taskset -c 6`), runs alternating. HEAD is `babe30a7e`, extracted at a path of the same length
(`/home/badlogic/pi-h7`); the build in the worktree (`/home/badlogic/pi-7a`).

**Paths under every object** (`test/bench/calls.ts`), median per operation over nine bursts, heap allocated per
operation, three alternating runs each, HEAD → build:

| Case | HEAD | build |
| --- | --- | --- |
| local method call (its ctx) | 2.81-2.82 µs, 6,894 B | 2.80-2.82 µs, 6,894 B |
| commit through a watched derive | 10.43-10.70 µs, 15,310 B | 10.38-10.53 µs, 15,310 B |
| activation churn: get, live, release (an object with params and one dependency) | 58.5-59.9 µs, 43,716-43,719 B | 53.7-55.4 µs, 41,540-41,559 B |
| retained per live object with one dependency (10,000 kept, an ad-hoc probe) | 7,398-7,406 B | 6,931-6,936 B |

An activation whose dependencies are live at the check does not park: one check of its bindings, then its own steps a
microtask later (as HEAD's wait did). The first build parked every attempt with a dependency (a waiter list, a
`parked_long` record, a microtask per wake even outside parking) and cost 62.0-63.6 µs and 580 B more per activation;
now a wake outside parking is a flag, the first-outcome promise is made only for whoever waits (the start barrier),
and an object keeps no `Set` of waits and no settlement promise per attempt (R18's), hence the lower numbers.

**Links** (`links.ts`, three runs each): wire sizes, encodes, decodes, heap per message and retained heap per hold
(176.0 → 175.4-176.0 KiB) unchanged. Hold to live over two hops (mean of 100), binary: 1,000-item list 0.781-0.817 →
0.807-0.811 ms, 500 KB document 1.250-1.278 → 1.289-1.310 ms (+1-3%: the hold counted at its arrival, the index
check of the publication); text 1.545-1.580 → 1.521-1.573 and 3.299-3.379 → 3.317-3.393 ms. Commits to frames,
streamed appends, call round trips and reconnects within the runs' spread.

**Existing benchmarks**, HEAD → build: the derive diamond (`derives.ts`, three runs) 9.4-10.1 → 9.5-9.6 µs median,
p95 19.3-19.9 → 19.3-19.4 µs. Registries (`registries.ts`, three runs): `writable.set` 0.82-0.97 → 0.77-0.87 µs; one of
10 contributions set 0.72-2.71 → 0.70-1.06 µs; of 100 1.50-3.46 → 1.44-3.40 µs (one slow run per side: JIT);
allocation within 20 B. A registry's last good composition keeps the list of contributions it was built from: the
list is replaced (not spliced) when a contributor comes or goes, so a composition costs no copy.

**Fix round 1** (2026-10-29: revocation over paths, retry operations on the wire, the provider's own host-address
check for same-host remote requests, mapped values' provenance), `calls.ts`, three alternating runs, HEAD → build:
local call 2.81 → 2.79-2.82 µs (6,894 B both), watched derive commit 10.45-10.70 → 10.35-10.47 µs, activation churn
58.6-59.8 → 53.9-54.2 µs (43,716-43,720 → 41,559 B); retained per live object with one dependency 7,399-7,405 →
6,930-6,938 B. The address check runs only for a remote type whose consumer and provider `hostAddress` differ; a
retry's operation id is made per `ref.retry()`, and an object keeps its handled ids only once it was retried.

## Slice 7b: reload in the kernel (2026-10-29)

Node 24.4.1, one CPU (`taskset -c 6`), runs alternating. HEAD is `0c3675e64`, extracted at a path of the same length
(`/home/badlogic/pi-hb`); the build in the worktree (`/home/badlogic/pi-7b`).

**Paths under every object** (`test/bench/calls.ts`), median per operation over nine bursts, heap allocated per
operation, alternating runs (the last two after the fixes below), HEAD → build:

| Case | HEAD | build |
| --- | --- | --- |
| local method call (its ctx) | 2.80-2.83 µs, 6,894 B | 2.67-2.70 µs, 6,757 B |
| commit through a watched derive | 10.38-10.69 µs, 15,309 B | 10.22-10.39 µs, 15,312 B |
| activation churn: get, live, release (an object with params) | 53.6-55.3 µs, 41,539-41,560 B | 54.2-55.6 µs, 41,606-41,630 B |
| retained per live object with params and one dependency (10,000 kept, an ad-hoc probe, median of 5) | 8,696-8,700 B | 8,761 B |

The first build cost 60.4-62.7 µs and 2,480 B more per activation: every attempt made an `AbortController` for its
routines and two maps (routine calls, job invocations) whether it had any. Now they are made when routines start or a
run is admitted, and the first dependency check's answer is a shared constant unless someone asks for it; what a reload
did to an attempt is one record made by the first such step. What remains: a few fields on the object (its params key)
and the attempt (its routines, its reload record, its first check), +46-70 B allocated and +61-65 B retained (0.7%).
A local call allocates 137 B less: the method path is split (`#invoke`) so the current version's call builds no
mapping closure.

**Links** (`links.ts`, two runs each): wire sizes, encodes, decodes and heap per message unchanged. Hold to live over
two hops (mean of 100), binary: 1,000-item list 0.780-0.794 → 0.797-0.821 ms (+1-4%), 500 KB document 1.246-1.275 →
1.270-1.275 ms; commits to frames and streamed appends within the runs' spread. Retained per hold of 10: 175.8 → 176.2-176.5
KiB (the hold keeps its request, to be placed again after a reload); the single-hold row 176.0 → 180.2 KiB is one
fixed amount (~4 KiB, code of the new paths), divided by ten in the other row.

**Existing benchmarks**, HEAD → build: the derive diamond (`derives.ts`, two runs) 9.5-9.6 → 9.6 µs median, p95
16.4-19.3 → 14.1-14.3 µs. Registries (`registries.ts`, two runs): `writable.set` 0.94-0.96 → 0.77-0.86 µs; one of 10
contributions set 0.77-1.05 → 0.69-0.72 µs; of 100 1.57-1.58 → 1.54-3.30 µs (one slow run: JIT, as in 7a). Jobs
(`jobs.ts`, two runs): start 8.6-8.7 → 8.5 µs in memory, 55.3-56.1 → 55.3-55.6 µs persisted; state changes within 0.1
µs. The store (`store.ts`): every median within 0.3 µs. The relay (`relay.ts`, three runs): tab B alone 0.014 ms both;
10,000 calls at once 530-723 → 491-785 ms (the spread of either side).

**Reload** (`test/bench/reload.ts`, new): 20 plugins, 1,000 live objects (with params, a document, a derive and a
method each), one plugin reloaded 20 times; medians after two warm-up reloads, two runs:

| Case | reload resolves | all live again | heap after 20 reloads, above after the first |
| --- | --- | --- | --- |
| swap, 50 of the 1,000 objects in the reloaded plugin | 1.58-1.59 ms | 1.64-1.65 ms | 332-338 KiB |
| swap, all 1,000 in it | 35.5-36.3 ms | 36.6-37.2 ms | 191-192 KiB |
| restart (a native each), 50 of 1,000 | 1.20-1.54 ms | 1.90-2.05 ms | 105-106 KiB |
| restart, all 1,000 | 20.0-20.2 ms | 35.8-40.8 ms | 57-58 KiB |

A swap costs about 36 µs per object (its staging record, the new attempt's activation, the hand-over of its old one),
a restart about 20 µs until the reload resolves (staging and the start of each fate; the new attempts activate after
the drains). The heap after reloads levels off (swap, 50 objects: 332 KiB after 20, 437 KiB after 80, 550 KiB after
300 reloads): compiled code and feedback of the new facets, not objects (the GC tests collect old attempts, removed
objects, providers and facets).

**Fix round 1**, CPU 6, alternating against HEAD. `calls.ts`, three runs: local call 2.80-2.82 → 2.66-2.68 µs
(6,894 → 6,757 B); watched derive commit 10.42-10.66 → 10.31-10.47 µs; activation churn 53.7-55.8 → 54.3-55.9 µs,
41,540-41,560 → 41,566-41,584 B (an `?? []` per end, found here, is gone: the round's first measurement allocated
41,698 B); retained per live object with one dependency 8,699-8,700 → 8,768 B. Links (a review measured binary
commit-to-frame +19% and small calls +6% on another CPU): `links.ts`, two runs, binary commit to frame
0.085/0.097-0.099/0.063-0.065 → 0.087/0.097/0.064 ms (append/change/removal), small call 0.038-0.039 → 0.035 ms. A
warmed ad-hoc probe (binary memory link, 2,000 calls and 1,000 commits per burst) measures no regression: call round
trip 9.8-10.2 → 9.9-10.1 µs, commit to frame 60.6-65.1 → 61.0-61.6 µs. Reload benchmark after the round: swap 50 /
1,000 objects 1.50 / 35.9 ms, restart 1.67 / 21.4 ms until the reload resolves (2.12 / 38.1 ms until all are live);
heap after 20 reloads 339 / 193 / 104 / 68 KiB.

**Fix round 2**, alternating against HEAD. Stock `links.ts` on CPU 22, six rounds each before and after the fix
(medians, binary / text): before, small call 0.062 → 0.068 / 0.058 → 0.064 ms (+10%), commit to frame within 1%
(append 0.156 → 0.156, changed field 0.165 → 0.162, removal 0.120 → 0.119 ms binary). Cut-down copies located it:
calls alone, or after the snapshot, commit and stream sections, or after the hold-memory trials alone, measured
equal; only the full sequence showed the gap, and a CPU profile of its calls section put the difference in the
remote call path (`Hold.call` with the attempt's call inlined, about 6.7 µs per call). The cause was `Attempt.call`
delegating the invocation to a helper method shared with the older-version path; one body for every version, and
no `async` (a local call allocated about 250 B more as an async function), fixed it. After: small call 0.063 →
0.065 / 0.058 → 0.058 ms, append 0.156 → 0.157, changed field 0.164 → 0.163, removal 0.119 → 0.120 ms, hold to live
(1,000 items) 1.037 → 1.023 ms. `calls.ts` on CPU 6: local call 2.89-2.92 → 2.77-2.85 µs (6,894 → 6,660 B), watched
derive commit 10.44-10.58 → 10.65-10.81 µs (15,309 → 14,969 B), activation churn 54.8-55.1 → 54.6-54.7 µs (41,560 →
41,592 B); retained per live object with one dependency 8,700 → 8,777 B. Reload benchmark: swap 50 / 1,000 objects
1.84 / 33.7 ms, restart 1.31 / 22.3 ms until the reload resolves (2.18 / 41.0 ms all live); heap after 20 reloads
323 / 200 / 104 / 70 KiB.

**Fix round 3: the commit-to-frame gap is V8's young generation, not frame work.** Astra (CPU 22, five pairs) measured
binary append commit-to-frame 132 → 161 µs, changed field 148 → 168, removal 112 → 121 on the stock `links.ts`.
- *Path length.* The HEAD copy `/home/badlogic/pi-hb` measured append 0.155 ms; Astra's `/tmp/s7b-hd-astra`, with
  identical sources, 0.129 ms. A copy of the same tree at a path of Astra's length (17 characters) measured 0.130 ms,
  at a longer one 0.155 ms: on the same code the result depends on the checkout path alone. Compare copies at paths of
  equal length.
- *Stock numbers, equal paths* (`/tmp/s7b-hd-astra` vs a fresh build copy `/tmp/s7b-xx-astra`, CPU 22, three
  alternating runs, means): append 0.128-0.129 → 0.155-0.156 ms binary, 0.106-0.107 → 0.116-0.117 text; changed field
  0.144-0.145 → 0.161-0.162 binary, 0.097-0.098 → 0.107-0.110 text; small call 0.061-0.063 → 0.065-0.066 binary,
  0.058-0.059 → 0.058-0.059 text.
- *Same work.* Heap allocated per commit is equal (191.9 vs 191.4 KB including the codec rows); so are the telemetry
  records per commit (5.012, the same names: two validations, two link checks, one encode).
- *The difference is scavenges.* In the timed append loop HEAD ran 5 scavenges costing 3.6 ms in total, the build 3
  costing 21 ms (changed field: 2 for 2.7 ms vs 1 for 10.9 ms). At the loop's start the young generation was 33.5 MB
  in HEAD and 67 MB in the build (134 MB by the changed-field loop): V8 grows it from the bytes surviving its
  collections, and the build crossed that threshold a few scavenges earlier. Over the whole run the GC work is equal
  (scavenge time 1,620 vs 1,605 ms, survived bytes 471 vs 480 MB, 285 vs 284 scavenges); where the expensive
  scavenges fall relative to the timed loops differs. Tracing the GC (`--trace-gc-nvp`) moves HEAD into the build's
  pattern by itself.
- *With the young generation pinned* the two are equal: means 0.139/0.139 ms (append), 0.145/0.144 (changed field),
  0.116/0.115 (removal), 0.065/0.064 (small call), HEAD/build; per-commit medians and p90s too (three runs, warmed
  script): append 0.085-0.086 / 0.085-0.086 ms median, 0.101 / 0.101-0.103 p90; changed field 0.073 / 0.072-0.073,
  0.083-0.084 / 0.083; removal 0.060-0.061 / 0.060-0.061, 0.073 / 0.072-0.073 (binary; text alike, within 1 µs).
- *The extra live heap is code.* Build minus HEAD after a full collection: +249 KB right after loading the modules
  (old space +229 KB, before any object), +290 KB after a snapshot section, +296 KB after 1,000 appends, +281 KB after
  1,000 edits, +345 KB after 70 hold trials (old space +259 KB, the rest bytecode and code as more paths compile). It
  does not grow with commits or holds beyond the retained-per-hold and per-object figures above.

So `links.ts` changed: each commit section runs 1,000 untimed commits first (`WARM_UP_COMMITS`; the removal section
starts with 1,000 more notes for them), and reports commit-to-frame as mean, median and p90 of the 1,000 timed commits.
The warm-up stays because the timed loop then runs nearer the young generation's steady size: the warmed medians
match the pinned ones (append 0.082 vs 0.085 ms, changed field 0.072 vs 0.073, removal 0.060 vs 0.060), and HEAD and
build agree in five of six sections, against two of six without it (run-to-run spread is about 1 µs either way). The
mean still carries the scavenges that fall in the loop. After the change, equal paths, CPU 22, three alternating runs,
HEAD → build (mean; median; p90, ms):

| Section | binary | text |
| --- | --- | --- |
| append | 0.106-0.108 → 0.142-0.144; 0.081-0.083 → 0.090-0.091; 0.093-0.096 → 0.125-0.127 | 0.095-0.119 → 0.121-0.125; 0.078-0.080 → 0.080-0.082; 0.090 → 0.094-0.095 |
| changed field | 0.084-0.087 → 0.098-0.099; 0.071-0.075 → 0.072-0.073; 0.081-0.084 → 0.081-0.082 | 0.086-0.090 → 0.099-0.101; 0.067-0.071 → 0.070-0.071; 0.079-0.082 → 0.082-0.084 |
| removal | 0.103-0.104 → 0.107-0.109; 0.060-0.061 → 0.060-0.061; 0.071-0.073 → 0.072-0.073 | 0.100-0.102 → 0.077-0.103; 0.058-0.060 → 0.059; 0.067-0.069 → 0.067-0.070 |
| small call | 0.052-0.058 → 0.053-0.054 | 0.054-0.065 → 0.059-0.069 |

The binary append differs unpinned (median +11%, p90 +31%) and is equal pinned: the young generation's size in that
section, not per-append work. To compare commit-to-frame across two copies, run both at paths of equal length, pinned
to one CPU, alternating, with the young generation pinned:

    taskset -c 22 node --min-semi-space-size=16 --max-semi-space-size=16 --conditions=source --expose-gc test/bench/links.ts

Fix round 3 hot paths, `/tmp/s7b-hd-astra` → a build copy at a path of equal length, CPU 22, three alternating runs
(`calls.ts`): local call 3.69-3.71 → 3.56-3.63 µs (6,894 → 6,660 B), watched derive commit 17.39-17.50 → 17.41-17.53
µs (15,310 → 14,967 B), activation churn 104.2-104.8 → 107.6-108.3 µs (+3%; 41,526 → 41,426 B); retained per live
object with one dependency 8,700 → 8,585 B (one table per version replaced the current version's separate member
map). Reload benchmark, same CPU: swap 50 / 1,000 objects 2.88 / 51.9 ms, restart 2.49 / 35.7 ms until the reload
resolves (3.22 / 65.7 ms all live); heap after 20 reloads 345 / 188 / 119 / 85 KiB.

Sol's independent runs (CPU 24, five pairs of the stock `links.ts`) show the same commit-to-frame gap (binary append
135 → 162 µs, changed field 145 → 168, text 109 → 119 and 100 → 108): the young-generation effect above. Sol's
isolated round trips (`sol-isolated-links.ts`, nine bursts each, no telemetry) measured a binary call at 44.83 → 47.20
µs (+5.3%) on the round-2 code. On this round's code, `/tmp/s7b-hd-astra` → a build copy at a path of equal length,
CPU 24, five alternating pairs, medians: binary call 47.23 → 45.74 µs (-3.2%; HEAD's samples are bimodal, 44.3 or
46.9-47.9), binary commit 92.68 → 93.28 (+0.6%), text call 39.02 → 39.76 (+1.9%), text commit 82.86 → 85.28 (+2.9%);
with the young generation pinned: binary call 45.45 → 43.85 (-3.5%), binary commit 92.73 → 93.06, text call 39.97 →
39.65, text commit 83.65 → 85.46 (+2.2%).

**Rework: references are the only indirection** (decision of the same name). `/tmp/s7b-hd-astra` (HEAD) → a build
copy at a path of equal length, CPU 22, three alternating runs. `calls.ts`: local call 3.72-4.03 → 3.62-3.77 µs
(6,894 → 6,660 B); watched derive commit 17.46-17.92 → 17.53-18.40 µs (15,310 → 14,900 B); activation churn
104.7-107.9 → 114.7-118.3 µs (+9.6%, accepted by the owner, 2026-10-29; 41,507-41,526 → 41,473-41,501 B). The churn's object derives over its dependency's
member: that derive now attaches through its own reference's member (one `ReferenceSource` made, bound and ended per
cycle) where HEAD shared the provider's one member source; the allocation is HEAD's, the time is the new node's (a
copy of round 6, before the rework, measured 55.2 µs against HEAD's 53.5-54.6 µs and the rework's 58.4 µs on CPU 6).
Retained per live object with one dependency (an ad-hoc probe, 2,000 objects, median of five): 6,924 → 6,738 B; a
first cut made a source for every member at the binding and allocated four sets per source (8,627 B): sources are made
on first use or when a reference that had values detaches, and a source's watch, subscriber and pass-through sets are
made by their first user. `links.ts` (warmed, mean / median / p90 in ms), binary: append 0.107-0.113 / 0.082-0.083 /
0.095-0.097 → 0.141-0.142 / 0.089-0.090 / 0.123-0.124 (the young-generation effect above), changed field 0.084-0.086 /
0.071-0.072 / 0.081-0.082 → 0.098-0.099 / 0.072-0.073 / 0.081-0.082, removal 0.102-0.108 / 0.060 / 0.071-0.073 →
0.107-0.109 / 0.060-0.061 / 0.072; with the young generation pinned, append 0.140-0.143 / 0.086 / 0.100-0.102 →
0.143-0.147 / 0.085-0.087 / 0.101-0.103, changed field 0.091-0.092 / 0.072-0.073 / 0.082-0.084 → 0.091-0.092 /
0.073-0.074 / 0.082-0.084, removal 0.108-0.111 / 0.061-0.062 / 0.072-0.075 → 0.108-0.110 / 0.060-0.062 / 0.072-0.076;
text alike within 3 µs. Small call 0.058-0.060 → 0.053-0.056 ms. Retained per hold (both ends): 175.4-176.0 →
176.4-177.0 KiB with one hold, 175.8 → 176.4 KiB with ten.

The 1 MiB call row (final review): one burst of 50 calls read 0.389 → 1.088 ms (binary, young generation pinned) in
one review run. Not per-call work: a probe with the row's setup and a collected heap before each of 20 bursts of 50
(CPU 22, three alternating pairs) measured, per call without the collector's pauses, 0.27-0.31 → 0.30-0.31 ms binary
and 0.31-0.36 → 0.33-0.36 ms text, heap 23,025 → 22,707 B binary and 23,964 → 23,650 B text. A burst's time is about
0.3 ms per call plus 0.2-0.27 ms per call when a full collection falls in it (the arguments fill memory outside the
heap); one burst of 50 sees one or none, in either tree. `links.ts` now collects the heap before each of 20 bursts and
reports the median and p90; three alternating pairs of the new row, stock, binary median / p90 0.386-0.455 /
0.409-0.473 → 0.279-0.357 / 0.306-0.394, text 0.344-0.395 / 0.510-0.566 → 0.363-0.500 / 0.522-0.621; pinned,
binary 0.689-0.910 / 0.738-1.050 → 0.695-0.882 / 0.829-0.992, text 0.415-0.896 / 0.958-1.049 → 0.534-0.864 /
1.042-1.175. The row still moves by run with the collector's phase; compare it across several runs, not one.
The small call, measured apart (ten bursts of 1,000 after 3,000 warm-up calls, three alternating pairs): stock, binary
29.5-30.6 → 27.6-27.9 µs and text 25.1-25.9 → 27.5-28.3 µs; with the young generation pinned, binary 29.7-30.7 →
30.3-30.7 µs and text 23.6-23.7 → 23.9-24.1 µs. The stock text gap is the young generation's sizing, as for commit to
frame above (pinned, the two match); the snapshot before the final review's fixes measures the same.

## Simplification audit (2026-10-30)

HEAD `4b535d57e` → the audit build (A1, A2, A5, A9-A12), copies at paths of equal length, CPU 6, alternating.
`calls.ts`, three runs: local call 2.70-2.73 → 2.69-2.73 µs (6,660 B both), watched derive commit 10.41-10.75 →
10.42-10.74 µs (14,899 B both), activation churn 59.0-60.9 → 59.1-61.4 µs (41,473-41,482 → 41,478 B). Retained per live
object with one dependency (10,000 kept) 6,745-6,754 → 6,745-6,752 B; a first cut of the declaration-ordered
dependency list (A11) kept it on live attempts, +225 B, and is now let go after the dependency check. `links.ts` with
the young generation pinned: commit to frame, hold to live and retained per hold equal within run spread (176.4 →
176.2-176.6 KiB per hold).

**Text-codec calls in isolation** (Sol's probe: a remote object over one memory link, 5,000 warm-up calls, ten bursts
of 1,000 small calls, then 200 warm-up and 30 bursts of 10 calls with a 1 MiB argument; binary first, then text; the
heap collected before each burst and the collections in it recorded: none in any burst), seven alternating pairs,
median of the pairs' medians:

| Case | stock | young generation pinned |
| --- | --- | --- |
| binary small | 26.53 → 26.37 µs | 25.72 → 25.90 µs |
| text small | 19.31 → 20.95 µs (+8.5%) | 19.11 → 19.93 µs (+4.3%) |
| binary 1 MiB | 985 → 993 µs | 539 → 412 µs (bimodal: 187-607 µs per run) |
| text 1 MiB | 958 → 963 µs | 273 → 284 µs (221-352 µs per run) |

Heap per call is the same (text small 15,171 → 15,160-15,202 B). The text small gap is not per-call work: the codec
alone (encode, decode and the message check of a call and a result message, 20,000 per burst) measures the same in both
trees (text call 1.55 µs and 52 B, result 1.52 µs and 171 B), deoptimizations and inlining decisions are the same, and
the gap follows the shape of the text decoder's `fromFields`, not what runs: the build with HEAD's `text.ts` matches HEAD
(19.0-19.2 µs), the one change in it that matters is the never-executed `T` (retry) case, and writing that case with an
object spread again (`...(f.length >= 2 ? { hops } : …)`) restores HEAD's 19.1 µs while other edits of the same size do
not. With text measured first the gap is 22.4-22.5 → 23.0-23.3 µs (+2-3%). V8 code generation, recorded as noise.

## Slice 7c: plugins (2026-10-30)

**The plugins component** (`test/bench/plugins.ts`, new): 20 plugins, one worker facet each (a store object over a
document, a derive, a method, a helper module and a copied contract; 80.9 KiB of scripts in all), Node 24.4.1. Medians
of seven runs; three runs pinned to CPU 8, one unpinned:

| Measurement | CPU 8 | unpinned (32 CPUs) |
| --- | --- | --- |
| cold build of the 20 worker facets (one esbuild build each, all at once) | 240.1-240.7 ms | 26.4 ms |
| rebuild of one facet after an edit | 13.1-13.3 ms | 11.0 ms |
| evaluation of one facet (`vm.Script`, its source map registered) | 0.16-0.27 ms | 0.09 ms |
| reload of one plugin on a host (evaluation and `host.reload`, a pure swap) | 0.44-0.45 ms | 0.44 ms |
| heap after 100 reloads of one plugin, against after a warm-up | +230-235 KiB | +229 KiB |

The heap does not grow per reload: 2,000, 4,000 and 8,000 reloads leave +897, +1,186 and +1,432 KiB (sublinear); the
same evaluations through plain `vm.Script` with V8's compilation cache off leave +420 KiB at 8,000 against +465 KiB
through `evaluateFacet` (V8's own per-script bookkeeping), and the kernel's reloads alone wander between +200 and
+600 KiB at any count. Old facets and their closures are collected (the GC test: 200 reloads, every facet but the last
two collected, the heap within 2 MiB of the warm-up).

Fix round 1 (inline source maps without `sourcesContent`: positions only), CPU 8: the 20 scripts take 53.4 KiB (80.9
KiB before); cold build 241.1 ms, rebuild 13.0 ms, evaluation 0.14 ms per facet, a reload 0.39 ms, heap after 100
reloads +238 KiB.

**Kernel hot paths** (per plugin at load and reload changes only staging), HEAD `18a155e2f` → build at paths of equal
length, CPU 6, three alternating runs. `calls.ts`: local call 2.69-2.71 → 2.71-2.75 µs (6,660 B both), watched
derive commit 10.34-10.36 → 10.43-10.49 µs (14,899 → 14,901 B), activation churn 58.93-59.58 → 59.44-59.73 µs
(41,452-41,470 → 41,470 B). `links.ts` binary commit to frame (median / p90): append 0.035-0.036 / 0.058-0.059 →
0.034-0.036 / 0.058-0.060 ms, changed field 0.027-0.028 / 0.031-0.033 → 0.027-0.028 / 0.031-0.033 ms, removal 0.022 /
0.026-0.028 → 0.022 / 0.026-0.027 ms; with the young generation pinned alike within 2 µs; text alike; small call
0.026-0.030 → 0.028-0.033 ms (pinned 0.030-0.035 → 0.030-0.032 ms); retained per hold equal (one binary hold 176.2 →
170.1 KiB). `reload.ts`: swap of 50 / 1,000 objects 1.44-1.73 / 30.83-32.71 → 1.52-1.53 / 30.55-33.25 ms, restart
1.01-1.05 / 15.54-16.87 → 0.95-0.99 / 15.90-16.02 ms until the reload resolves.

## Slice 10: HTTP and workers (2026-10-31)

`test/bench/http.ts` and `test/bench/workers.ts`, Node 24.4.1, CPU 6 (the forked workers inherit the pin).

| Measurement | Result |
| --- | --- |
| keep-alive round trip, a JSON body: plain Node handler / a route (same process as the client) | build: 42.0-42.5 / 46.4-47.0 µs: +4.2-4.9 µs (9.9-11.7%); fix round 1: 42.5-42.9 / 62.8-64.4 µs: +20.3-21.5 µs |
| the same after 30,000 warm-up requests (fix round 1) | 30.9-31.3 / 43.4-44.0 µs: +12.1-12.9 µs; with an authenticator reading `request.headers`: +15.9 µs |
| the same, server and client in two processes (CPU 6 and 8; build) | 36.4-37.0 / 41.7-42.4 µs: +5 µs |
| 100 MiB file: `pipeline` of a read stream / `fileResponse` | build (64 KiB reads): 602-618 / 487-565 MiB/s; fix round 1 (256 KiB, pulled): 477-751 / 560-611 MiB/s |
| a worker's cold start with one shipped script: fork to `started` / to `ready` (median of 7) | 531-532 / 538-539 ms |
| the server's heap per idle worker (20 workers, one reference each) | 49.5 KiB |

A request's overhead was 16 µs at first: `host.root` cost about 7 µs of it per request (a linked abort signal, a
`Promise.race` and an `awaitWithContext` per scope). Root scopes now take the caller's signal with one listener and
settle one promise (`root.ts`; behaviour and tests unchanged): 4.2-4.9 µs, about the bar of 10% of a round trip. The
rest is the request's scope (its abort controller, `CallContext`), admission and the response's header merge. The cold
start is mostly Node's startup stripping the types of the source tree it imports; the start timer (60 s) is far from
it.

**Fix round 1** (the `fetch` core, the security baseline, Chord's listener as a native object). A route's overhead in
the standard run grew from +4.5 µs to +20-21 µs (+41 µs before the Node fast path: the listener reads Node's parsed
headers and makes a Web `Request` only when something reads `request.headers` or the body or a relay verifies; whole
bodies are written as strings, in one write with the head). Warmed, +12-13 µs; a CPU profile of the warmed route path
(per request, `test/bench/http.ts`'s route): the listener's request function 13.6 µs inclusive against the plain
handler's 8.9 µs, of which writing the answer 8.3 µs (the plain handler's `writeHead` and `end`: 9.1 µs); `serve` 4.2
µs (the root scope 2.1, the URL parse 0.9, default headers 0.6, admission and routing 1.1, the answer 0.7); the root
scope's seal in a later microtask 0.9 µs. The baseline's extra headers cost 0.4 µs (a plain handler sending them).
The rest, about 5 µs, sits in no function of the component: Node's tick and microtask machinery (33 µs inclusive
against 18 µs for the plain handler). Opus's two trims are in (`lookup` decodes only segments with `%`; one abort
controller per request: the Node side's own is gone). Kernel rows, HEAD `bc9a20f84` → fix round 1, CPU 6, alternating:
binary 1 MiB call median 0.182-0.220 → 0.196 ms; reconnect of 1 / 100 references 1.02-1.10 / 79.1-80.3 → 1.04-1.05 /
81.3-81.5 ms; watched `writable.set` 0.836-0.868 → 0.861-0.863 µs; watched derive commit 10.42-10.58 → 10.36-10.60 µs;
activation churn 58.9-60.5 → 59.1-60.8 µs.

**Kernel hot paths** (routes without a timer, `RouteHandle`, `Path` events, root scopes), HEAD `bc9a20f84` → build at
paths of equal length, CPU 6, alternating runs. `calls.ts`: local call 2.70-2.83 → 2.70-2.83 µs (6,660 B both),
watched derive commit 10.36-10.60 → 10.34-10.79 µs, activation churn 59.43-61.30 → 59.48-60.72 µs. `links.ts`: commit
to frame and encode/decode alike; reconnect of 1 / 100 references 0.94-1.15 / 80.8-84.0 → 0.94-1.15 / 80.6-86.5 ms;
1,000 parked calls 24.4-25.2 → 24.3-24.6 ms. `reload.ts`: swap of 50 / 1,000 objects 1.44-1.55 / 30.78-31.42 →
1.32-1.56 / 31.20-31.83 ms, restart 0.96-0.98 / 15.75-16.34 → 0.95-1.10 / 15.91-15.94 ms until the reload resolves.
`registries.ts` alike (one of 100 contributions set 1.47-2.45 → 1.48-3.41 µs, run to run).

## Slice 12: the plugin model (2026-11-01)

**The build's checks** (`test/bench/plugins.ts`, the 7c set: 20 plugins, one worker facet each, a copied contract
by relative path), Node 24.4.1, CPU 8, medians of seven runs, three alternating runs. HEAD `ebce9debd` (its bench
importing the contract by plugin name, which HEAD resolves) → this build: cold build of the 20 facets 257.6-257.8 →
257.2-258.8 ms, rebuild of one facet 13.2-13.5 → 13.3-13.9 ms. With the app's API set and the kinds named (every
import checked by version and kind, every resolved file by its kind segment; the plugins importing `@bench/app/v1`):
257.4-258.8 ms cold, 12.9-14.3 ms rebuild, against 258.2-259.7 ms without. The checks cost nothing measurable; no hot
path changed (the kernel gains two accessors read only by `testPlugin`).

Fix round 1: the bench itself now builds with the app's API and the kinds (its plugins import `@bench/app/v1`; Opus
L5), and every package file's real path is checked against the plugin's `node_modules`. CPU 8, three runs: cold
build 261.1-270.2 ms, rebuild 13.6-14.4 ms (the first two runs as before, the third with a slower cold build on a busy
machine).