@adobe/ecs 0.0.0-stage → 0.2.0

package/src/implementation/world/perf.md

@@ -0,0 +1,476 @@
+# Performance
+
+Measured on an Apple M1 Max (8 performance cores, 2 efficiency cores). Node numbers come from `pnpm perf`, a Vite bundle run on plain node; vitest's node transform turns imported bindings into getters and roughly doubles JS-heavy costs, so it is not used for comparisons. Browser numbers come from `pnpm test:perf` in chromium with real workers, where timers are quantized to 5 µs; "framed" numbers run once per animation frame and report the median and 90th percentile, which vary up to 2× between sessions. Every number is the fastest run within a time budget.
+
+## Results
+
+Baseline is commit `a28ba8cb`, before the optimization pass.
+
+| Benchmark | Baseline | Now | Gain |
+|---|---|---|---|
+| create 100K (spawn plus sync point) | 170 ms | 27.6 ms | 6.2× |
+| churn 100K (despawn and respawn 10%) | 17.0 ms | 5.05 ms | 3.4× |
+| retag 100K (archetype moves for 20%) | 18.0 ms | 7.04 ms | 2.6× |
+| emit 100K (commands from a kernel) | 6.65 ms | 0.97 ms | 6.9× |
+| sparse changed 1M, uniform 1% | 3.48 ms | 1.15 ms | 3.0× |
+| sparse changed 1M, clustered 1% | 3.13 ms | 0.021 ms | ~150× |
+| follow 100K (a lookup per row) | 10.6 ms | 0.38 ms | 28× |
+| move 1M (250K rows processed) | 0.259 ms | 0.095 ms | 2.7× |
+| chain, 6 dependent kernels over 100K | 0.476 ms | 0.343 ms | 1.4× |
+| main thread, 50 systems over 1K | 2.89 ms | 1.64 ms | 1.8× |
+| select 100K (`where` plus reads) | 18.1 ms | 3.1–4.5 ms | ~5× |
+
+Chromium:
+
+| Benchmark | Main thread | Workers (default pool) |
+|---|---|---|
+| move 1M | 0.305 → 0.105 ms | 0.105 → 0.020 ms |
+| follow 100K | 8.76 → 0.44 ms | 1.02 → 0.075 ms |
+| chain 6×100K | 0.67 → 0.405 ms | 0.455 → 0.115 ms |
+| sparse changed 1M | 4.78 → 1.095 ms | 0.74 → 0.19–0.25 ms |
+
+At 1M entities, against commit `d6373560` (claimed splits in place):
+
+| Benchmark | Before | Now |
+|---|---|---|
+| create 1M | 325 ms | 88 ms |
+| create flat 1M (ecs2's test: 8 scalars per entity) | | 70 ms; 223 ms with value objects built first |
+| churn 1M | 54 ms | 17 ms |
+| retag 1M | 79 ms | 42 ms |
+| emit 1M | 11.2 ms | 10.6 ms |
+| move 1M | 0.177 ms | 0.091 ms |
+| chain 6×1M | 3.42 ms | 1.51 ms |
+| main thread 50×1K | 1.65 ms | 0.48 ms |
+| select 1M | 37.5 ms | 24 ms |
+| follow 1M, sparse changed 1M | | unchanged |
+| chromium move 1M, main / workers | 0.20 / 0.030 ms | 0.095 / 0.015 ms |
+| chromium chain 6×1M, main / workers | 4.47 / 0.725 ms | 1.72 / 0.275 ms |
+
+Moving the code into `src/interface` and `src/implementation`, with ticks added, measured within noise of the record before it (`f9e8d10a`) on every node and chromium benchmark: run idle 333 ns, run 50 idle 109 ns per system, sync point one spawn 1.04 µs, create 1M 91 ms, churn 19.5 ms, retag 35.7 ms, move 1M 0.090 ms, chain 1.54 ms, select 8.27 ms; in chromium, move on workers 0.015 ms and chain on workers 0.29 ms. A run checks the `workers` resource by its changed tick, allocating nothing, and makes the loop due only while systems are added.
+
+Components, resources and traits are keyed by symbols, and the benchmarks moved to symbol keys with them (record `d4256133`, against `4aa829f4` on string keys): every benchmark is within noise but two. `create flat dynamic`, which builds value objects first and spreads them, went 224 → 434 ns per spawn, since V8 lists an object's symbol keys without the enumeration cache `Object.keys` has for strings. `retag` went 35.8 → 33.6 ms, since its literal `commands.add(entity, { [tag]: true })` is now a prepared site; through value objects it measured 43.9 ms. `create`, whose spawns are prepared sites, stayed at 90–94 ms.
+
+**Key reading** (`perftest/keys.ts`, `node dist/perf/run.js --keys`): nanoseconds per values object built and read, for 1 to 6 keys. Listing dominates: reading the same values by keys known in advance costs 58–73 ns, mostly the reads themselves.
+
+| Method | 1 | 2 | 3 | 4 | 5 | 6 |
+|---|---|---|---|---|---|---|
+| `Object.getOwnPropertySymbols` (kept) | 98.7 | 119 | 141 | 168 | 190 | 214 |
+| `Object.keys`, then `Object.getOwnPropertySymbols` | 106 | 123 | 145 | 175 | 196 | 217 |
+| `Reflect.ownKeys`, symbols only | 104 | 124 | 146 | 171 | 195 | 219 |
+| string keys with `Object.keys`, for comparison | 22.8 | 31.6 | 41.0 | 49.3 | 58.3 | 65.2 |
+
+So literal spawns and adds in main-thread systems are prepared sites, which list no keys and build no object; only values objects built at runtime pay for listing.
+
+Archetypes and commands that name their components first (record `bd0dabcc`, against the baseline `4e63c933`, which added a benchmark per kind of structural change): every benchmark is within noise or faster but `spawn bulk kernel` (120 → 131 ns, +9%, every component a kernel's list names now gets a value, its tag's start included) and `spawn singles` (458 → 490 ns, +7%). Faster: `create` 90.6 → 58.1 ns per spawn, `create flat dynamic` 434 → 93.7 ns (beating string keys' 224 ns), `spawn sixteen archetypes` 757 → 57.6 ns, `spawn bulk` 49.8 → 40.7 ns, `despawn bulk` 65.2 → 44.2 ns, `remove tag` 107 → 72.4 ns, `remove several` 152 → 79.2 ns, `add tag kernel` 104 → 85 ns, `add value` 109 → 96 ns; `create flat` 69.8 → 66.8 ns, `add tag` 107 → 100 ns, `add several` 140 → 142 ns, `retag` 35.6 → 33.9 ms. Chromium is unchanged.
+
+- **Spawners are generated per shape:** one read by key and one store per value, so each read sees one object shape. Against a loop over the shape's columns, which is what runs where `'unsafe-eval'` is forbidden: `create` 58 against 126 ns, `create flat` 66 against 127 ns, `create flat dynamic` 94 against 172 ns, `spawn bulk` 41 against 59 ns.
+- **Literal spawns and adds stay prepared:** without the plugin's per-site functions, the values object costs about 25 ns for eight keys, so `create flat` measured 86 ns against 66 ns, and `add several` 169 against 142 ns.
+- **Archetypes are found by their index:** with only the eight-entry cache, sixteen archetypes from one site resolved their list on every spawn, 523–561 ns; the per-world table by archetype index, and a site's plans by index, take it to 57.6 ns.
+- **Moves are grouped by pair of archetypes,** copying shared columns for a block of rows, and rows left are removed last entry first, so an archetype that moves out whole drops its rows without copies; list adds and removes resolve their target once per source archetype.
+
+Sync point fixes for spawns (record `ebde4c9b`, against `bd0dabcc`): `spawn bulk kernel` 131 → 121 ns, back to the baseline's 120, and `spawn singles` 500 → 292 ns, below the baseline's 458; every other node and chromium benchmark within noise (`run idle` reads 333 or 375 ns from one record to the next, as timer steps; `bd0dabcc` measures 375 ns beside this one). Kernels reading lists from other modules changed only what the compiler emits. Each step, measured on its own:
+
+- **A pair whose entries are consecutive needs no ordering pass,** as a system's spawns or moves from one archetype are, and rows are removed only when some entry leaves one: `spawn bulk kernel` 130 → 127 ns. Reading entries through a branch per row instead of an identity order cost `retag` +3%, so the order is still written, in one sequential pass.
+- **The plan grows once per buffer,** since each command adds at most one entry, rather than checking capacity at every entry: `spawn bulk kernel` 127 → 120 ns; `retag` 34.5 → 33.5 ms.
+- **A spawn batch keeps its archetype,** rather than finding it by its joined ids at every sync point: `spawn singles` 489 → 396 ns.
+- **A batch of at most eight rows commits element by element,** since a subarray to copy from costs more than the rows: `spawn singles` 396 → 292 ns.
+
+Kernel spawns staged as main-thread spawns are (record `2b07c576`, against `ebde4c9b`): `spawn bulk kernel` 121 → 10.3 ns, now below `spawn bulk` from a main-thread system, which went 40.4 → 25.4 ns with it; `spawn sixteen archetypes` 56.5 → 41.1 ns. In chromium, the new `spawn bulk kernel main` and `spawn bulk kernel workers`, measured on `ebde4c9b`'s implementation first: 128 → 11 ns on the main thread, 177 → 7.65 ns on workers. Every other node and chromium benchmark is within noise (`create` reads 58–62 ns from one run to the next on either side, and node `sparse changed` 0.32–0.37 ms, as in records since `c234c41a`). Each step, measured on its own:
+
+- **Kernel spawns are staged in batches,** through a spawner per spawn list generated as main-thread spawners are, rather than issued as commands the sync point plans and writes value by value: 120 → 34 ns; in chromium 128 → 18 ns on the main thread and 177 → 54 ns on workers. A main-thread runner's batches and each chunk's buffer naming the rows it staged keep the row order the same whichever thread ran each chunk.
+- **The reused indexes a sync point reserved are copied as a typed array,** not an array of numbers: `spawn bulk kernel` 34 → 18 ns, `spawn bulk` 41 → 25 ns, `spawn sixteen archetypes` 58 → 41 ns.
+- **Kernel spawners reserve entities in blocks,** so workers spawning together don't contend for one atomic cursor, and the sync point returns the positions a block left unused to the free list: on workers 54 → 7.5 ns, on the main thread 18 → 10.5 ns.
+- **Runners stage only when their kernel spawns:** without the check, `run 50 idle` measured 120 against 110–112 ns per system.
+
+The shared layout directory (threads.md, phase 1), against `1a18c6a7`: workers find archetypes and the entity table through records in shared memory, so a sync point that grows archetypes posts no message and leaves workers' windows open. In chromium, `sync point grow 100 archetypes workers` (one spawn into each of 100 full archetypes, then a kernel over them) 1.43 → 0.62–0.68 ms and `spawn bulk kernel workers` 7.7–7.95 → 7.15–7.5 ns; `sync point grow 100 archetypes main`, `loop tick idle` and every node benchmark are within noise.
+
+Command rings for the pool (threads.md, phase 3), against `efedcd21`: worker kernels write their commands into a ring in shared memory as the columns of a `CommandBuffer`, and the world drains a segment by taking views of them, its structs' values staying bytes in the ring, rather than receiving buffers by message. The new `emit workers`, alternating against `efedcd21`'s message path: in node 6.35–6.48 against 6.94–7.03 ms, in chromium 7.76–7.8 against 8.13–8.22 ms. In chromium the run splits into the tiers, 1.15 against 1.9 ms, and the sync point, 6.05 against 5.85 ms: planning reads the columns where workers wrote them, 2.63 against 2.36 ms for freshly deserialized ones, about 3 ns more per command. `emit main` and every must-not-regress benchmark are within noise of `efedcd21` on both.
+
+The adobe/data ECS runs move 1M in 0.09 ms, single threaded with WASM SIMD, and creates 100K in 5.8 ms by inserting directly, with no command buffer or sync point.
+
+Observer systems (P1 of the observers plan), alternating against `af4c72f4`: every node benchmark within noise but `run 50 idle` 110 → 73 ns a system, from three changes to a runner's start that every run takes; `run idle` 416 → 375–416 ns, `loop tick idle` 1.84 → 1.81 µs, `read run` 10.9 → 10.5 µs. New: `run observer` 208 ns against 375–416 for `run idle`, `read run observer` 7.9–9.3 µs against 10.5–11.8 for `read run`, `observer idle 100` 81–85 ns an observer system a tick, about 19 of it the tick's own cost shared over a hundred. Each step, measured on its own:
+
+- **A run's chunks get their length set only when it differs:** writing an array's length is a runtime call even when it's unchanged: `observer idle 100` 122 → 94 ns, `run 50 idle` 112 → 88 ns.
+- **Conditions are checked only by a runner that has some:** `observer idle 100` 94 → 86 ns, `run 50 idle` 90 → 80 ns.
+- **A run starts on the runner's first buffer and chunk directly,** with nothing staged yet to stage: `observer idle 100` 86 → 78–83 ns, `run 50 idle` 80 → 73 ns.
+- **Each list of observer systems keeps its runners,** read again only once runners change, with whether any looks up through an index, rather than finding each runner by its system twice a pass: `observer idle 100` 144 → 122 ns.
+
+Observer systems on joined threads (P3 of the observers plan), alternating against `ffea07de`: every node benchmark touched within noise (`run idle`, `run 50 idle`, `run observer`, `observer idle 100`, `loop tick idle`, `sync point one spawn`, `remote run`, `handoff`, `fused tiers`, `tail prompt`, `read run`, `read run observer`, `loop tick add remove`, `create`, `follow`), and in chromium `loop tick idle` and `remote run`. New: `joined observer resource` 6.4–6.8 µs a tick in node, 9.3 in chromium; `joined observer 10K` 0.30 ms in node, 0.28 in chromium. Back to back, the world outruns the thread's wake-up, so most posts are cancelled before the thread claims them and the 10K sort runs about one tick in five there; the world's cost is the sync points and writers waiting for posts in progress, and the waited-for post after four cancelled ones.
+- **A run of observer systems alone skips its sync point** while nothing is queued and there's no GPU, joined thread or tail: `run observer` 375 → 208 ns, `read run observer` 8.8 → 7.7 µs.
+
+Observer factories, alternating against `799a0e1a`, every other node benchmark touched within noise (`run idle`, `run 50 idle`, `run observer`, `observer idle 100`, `loop tick idle`, `sync point one spawn`, `follow`, `create`, `remote run`, `joined observer resource`, `read run`, `read run observer`, `loop tick add remove`), and in chromium `loop tick idle`, `remote run` and `observe gpu entity factory`:
+- **An observer system added again registers at once with the runner it had,** restarted from tick 0, once the run that removed it is done: `read observe factory cold` 5.8 µs (14.1 at the old 300 rounds) → 0.88 µs. What's left is the reader's run with the maintenance system and the notifier in its pass, the notifier's add, and the promise and flush around them.
+- **Runs read resources without allocating:** a context binds each resource's storage and the resource entity's row, `changed` filters on resources read stamps by id, and the device check reads its cell directly. With one pass kept for the list of added observer systems rather than one per list (each add or remove makes a new list), a cold read 958 → 833 ns.
+- **A scan of one entry with at most one test, every entity or a count, gathers in the scanner's body,** without a call per row through an acceptance and a gather, and each scan's value is made at its length rather than grown: `select factory` 10.2 → 7.5 ms. An observer row system testing and writing a typed array alone takes 2.0 ms over the same 1M rows: the gap is the row body's calls.
+- `observe 1K entities one changed factory` (29.5 µs) and chromium `observe gpu entity factory` (450–468 µs) cost each entity's lookup by entity, and entity observers are mainly for debugging.
+
+Observer factories on a joined thread's world (C2 of the observers plan), and the fixes to observer posts it found, alternating against `320260b0`, node; every touched benchmark within noise but `joined observer 10K` (`joined observer resource` 6.8–8.4 µs a tick there against 7.2–7.6, `remote run`):
+- **New:** `joined resource factory` 6.5–7.8 µs a tick back to back, about a plain observer system's (`joined observer resource`); at a display's cadence, frames 2 ms apart, `joined resource factory cadence` 21–32 µs of the world's thread a tick, a plain observer system's the same: what's left is posting an observer system there (the writer's copy of what a post reads, settling posts at the sync point, waking the thread). `joined select 10K factory` 0.51–0.55 ms a tick: an unpaged ordered selection sorts on the joined thread through an index without a key, where the sorted index the world's thread keeps for one cost 0.74–0.95 ms. In chromium, three rounds: `joined resource factory` 9.4–11.3 µs (`joined observer resource` 9.0–10.7), at the cadence 24–30 µs, `joined select 10K factory` 0.43–0.65 ms.
+- **`joined observer 10K` 0.35–0.54 ms → 0.52–0.69 ms a tick:** posts are now claimed only once written and marked handled by the post claimed, so the world waits, past four cancels, for a post the thread really runs; before, a thread claimed a half-written post, ran it again once it saw its posted word, and the world, settled by the first run's done word, went on without waiting (and once in 13 runs waited for good on a post the thread had marked handled unclaimed).
+
+Observer posts on joined threads holding copies, alternating against `e3f51fb3`, node, three rounds on a machine loaded by other work; every other touched benchmark within noise (`joined observer 10K` and `joined select 10K factory` over six rounds, `remote run`, `run idle`, `run observer`, `observer idle 100`, `read run observer`, `read observe factory cold`, `loop tick idle`, `handoff`, `tail prompt`), and in chromium `remote run` and both 10K benchmarks over five rounds:
+- **An observer system reading only struct resources posts copies of them,** its head's flags and its resources' values, so writers and sync points leave its posts alone; the next post cancels one no claim reached, takes the outcome of one that ran, and goes into a second block while the thread runs one, its outcome taken as its flags say. Back to back, `joined resource factory` 6.9–8.2 → 4.3–5.3 µs a tick and `joined observer resource` 6.9–9.9 → 4.3–5.0; in chromium 10.0–10.4 → 7.0–8.1 and 9.3–10.5 → 7.2–7.5. Before, back to back, the world copied each post's resource for its next writer (0.54 µs a call through the tail snapshot), settled it at the sync point, and waited, past four cancels, for the thread's wake-up and run (2,746 waits in 20,000 ticks).
+- **At a display's cadence the cost is cache lines and cold code,** not work: frames 2 ms apart, a post's writes take 0.13–0.29 µs on its first line, which the thread's claim last wrote, and its whole pass 3.3–4.3 µs a tick at the median. So a post writes only its block's first and last lines: its snapshot's words once, its flags when they change, its resources in its last line up to 80 bytes, and an end new each post, so the thread's done word needs no reset; its head is worked out once, and with nothing the GPU wrote to read back it's written at once, without a list of posts. Two worlds in one process, a frame each in turn, 500 ticks each over six rounds, three processes: `joined resource factory`'s world 9.0–9.8 µs a tick at the 10th percentile and 17.5–20.9 the mean of the middle half; at `e3f51fb3`, 2.3–4.6 µs more at the 10th percentile. The cadence benchmarks, a process each, still vary up to twofold with the machine's load: `joined resource factory cadence` 34–41 → 18–35 µs.
+- **An observer pass whose systems all run on joined threads** skips the world's own pass over them.
+- **The cadence benchmarks give the mean of the middle half of 1,000 ticks,** after 1,000 to warm up, rather than the least of eight stretches of 100: a few ticks take many times the rest.
+
+Benchmarks read through observer systems and the factories (E of the observers plan), alternating against `e3f51fb3`, 3 to 5 rounds in node and 2 in chromium, and the joined, cadence, `remote run`, `tail` and `handoff` ones again against `8ce1ea60` (observer posts holding copies, the cadence benchmarks' mean of the middle half), 4 rounds in node. Ticks back to back are counted by an observer system filtering on the clock's `changed`, reading nothing (`perftest/observer.ts`); what's read before the timed runs is read by observer runs, which leave nothing added, and results are checked through the factories once nothing more is timed, as they keep their maintenance system added; the cadence benchmarks time each frame until the loop asks for the next, its tick done, rather than until an observer of the clock was notified. Every touched benchmark is within noise in node (`loop tick idle`, `observer idle 100`, the `loop tick add remove` ones, `tail prompt`, `tail late snapshot 10K`, `tail overlap`, `tail overlap waiting`, `handoff`, `fused tiers`, `remote run`, the joined ones, `joined resource factory cadence`, `create flat`, `create flat dynamic`, `move`, `churn`, `retag`, `emit`, `emit main`, `reduce`, the `up` ones, the `lookup 1K entities` ones) and in chromium, two rounds of the suite each side on a busy machine (`loop tick idle` 4.4–4.6 µs both, `tail prompt`, `handoff`, `remote run`, the joined ones, `transfer`, the placed ones), but one:
+- **A tick's clock can't tell a tick from the last in chromium:** its timer is coarse enough that back-to-back ticks share a `now`, so a counter skipping a clock whose `now` it had seen counted too few ticks there: `loop tick idle` 4.3 → 6.0 µs. The counter filters on `changed` instead; a tick-count wait (`ticksAfter`) tells ticks by their count and `now` together, as the first tick's count is 0, as before it.
+- **The order modules load in matters:** imports added at the top of `benchmarks.ts`, or `src/observe` and a module reading the clock imported where they weren't, reordered the bundle's shared chunk or which keys register first: `tail prompt` took 26 µs a tick against 21 in node, `remote run` 16.5 against 12.4 in chromium. New imports come last, or where the clock's was.
+
+The built-in observers and mailboxes removed (F of the observers plan), alternating against `87a81495`, node, four rounds and six for the closest: runs and ticks no longer start, read back for or deliver to observers. `run observer` 208 → 166–167 ns, `run idle` 375 → 334–375 ns, `joined resource factory` 5.0–5.3 → 4.3–5.0 µs a tick, `joined observer resource` 4.4–5.6 → 4.1–4.6 µs; within noise: `run 50 idle`, `observer idle 100`, `loop tick idle` (1.72–1.85 against 1.71–1.79 µs), `sync point one spawn`, `remote run`, `handoff`, `fused tiers`, `tail prompt`, `tail late snapshot 10K`, `tail overlap`, `joined observer 10K` (0.40–0.49 against 0.40–0.47 ms), `joined select 10K factory`, `read run observer`, and `read run`, 9.5–11.4 against 10.1–11.8 µs, a new system each read.
+
+A report for every run and tick, `Report.run` written in place and `Report.errors` only with errors, alternating against `76f4670e`, node, six rounds, medians: `run idle` 333 → 458 ns, `run observer` 166 → 291, `run 50 idle` 3.63 → 3.75 µs a run, `loop tick idle` 1.70 → 1.92 µs a tick, `sync point one spawn` 875 → 1,000 ns, `read run observer` 7.9 → 9.1 µs, `remote run` 10.0 → 10.6 µs, and `run failing` 12.0 → 9.9 µs, its errors joining its own sync point rather than one of their own.
+- **About 125 ns a run:** two `performance.now()` calls for `elapsed`, 31 ns each, then locating the report, writing its struct and stamping it.
+- **`Report.run` is written field by field** through its layout's leaves, not the general struct writer: `run idle` 583 → 500 ns, and `run observer` 375 → 291.
+- **What a tier ran is worked out once per list of runners:** counting each runner every run took `run 50 idle` to 4.08 µs a run.
+- **A world's first 256 runs each spawn their report,** so each has a sync point applying a spawn: 3.2–5.1 µs a run in node against 1.1–1.5 µs once reports are reused, about 1 ms over a world's life. One command buffer spawns every report, 3.8–5.7 → 3.2–5.1 µs. Benchmarks timing a run after another (`after` in `perftest/benchmarks.ts`) warm up past the 256, so they time a world's steady state: the filtered `up` benchmarks timed the spawn's sync point instead, `up one root changed` 0.042 against 0.024 ms, `up filtered after a reparent` 0.028 against 0.018, `up small tree in a big world` 0.020 against 0.011.
+- **A reused report keeps its errors and takes new ones in place,** so a run with a blocking tier every tick changes no archetype, and its sync point isn't one tails wait for.
+
+Strings in shared memory, alternating against `c6bb3c83`, node, five and six rounds, medians: every touched benchmark within noise (`run idle` a mean over 20,000 runs 626–644 against 622–660 ns, `run 50 idle`, `run observer`, `loop tick idle`, `sync point one spawn`, `move 1K`, `main thread 1K`, `spawn bulk`, `despawn bulk`, `despawn one`, `add tag`, `add value`, `remote run`, `joined observer resource`, `joined observer 10K`, `handoff`, `tail prompt`, `tail late snapshot 10K`, `despawn objects 10K` 97.5 against 97.7 ns).
+- **The world's thread holds strings as values,** as it does objects, and reads and writes them there: `string read 10K` 2.78 ns a row, as `object read 10K`; `string write 10K` 19.5 ns, `object write 10K` 20.5.
+- **Records only while a joined thread may read them:** `string write 10K joined` 126 ns a row, a new record each and the old one let go. Most of it is copying the code units out of a string just made, which flattens it first: in a microbenchmark, 106 ns a 30-character label made and copied against 37 copied once flat.
+- **A joined thread reads a string out of its record, decoded once per record:** `joined observer strings 10K` 358 µs a tick, an observer system there reading every caption after each sync point while the world rewrites 1% of them, against 309 µs for `joined observer numbers 10K` reading numbers.
+- **Records up to 512 bytes are carved from slabs** by power-of-two size class: `string write 10K joined` 142 → 127 ns against the arena's blocks, whose size class costs a `Math.log2` per record.
+- **A removed row lets go only of its archetype's string storages,** listed once per archetype: `despawn objects 10K` 104 → 97.7 ns against a check of every storage.
+
+A joined thread's finalizers reading its object resources from its mirror, alternating against `998738a3`, node, three rounds: `despawn objects 10K` 98.2–102 against 99.6–103 ns, within noise. The mirror's archetype holding the resource entity is found once per group of stops that reads one, kept and checked before it's searched for again.
+
+A joined thread's finalizers reading string resources from copies in the stop list, once per group, alternating against `13eb6d6f`, node, six rounds, medians, on a machine busy elsewhere: all within noise. New `despawn objects 10K string resource`, the despawn benchmark's finalizer reading a string resource too, 95.5 ns a despawn against 99.5 reading the live record (the benchmark run on the old build); `despawn objects 10K` 98.0 against 97.2 ns, `string write 10K joined` 129 against 129 ns, `joined observer strings 10K` 478 against 500 µs a tick. Finalizers reading no string resource copy nothing and the group holds no extra bytes.
+
+Their linear resources copied into the stop list too, once per group, alternating against `92b823c9`, node, six rounds, medians, on a machine busy elsewhere: all within noise. New `despawn objects 10K linear resource`, the finalizer reading a number and a vec3 resource too, 99.5 ns a despawn against 99.1 reading them where they are (the benchmark run on the old build); `despawn objects 10K` 100.5 against 101.0 ns, `despawn objects 10K string resource` 98.4 against 99.3 ns, `joined observer 10K` 584 against 567 µs a tick, a path this doesn't touch, its rounds spread 500–754 µs.
+
+Sync points waiting only for tails that read the world's memory, against `c21e8e1e`, node: `tail late snapshot 10K` 474–484 → 9.0–9.5 ns a row copied, against 8.9 for `e3c30aa1` measured beside it (its record 8.2), and in chromium 450 → 6.0 ns (its record 5.0, one or two 5 µs timer steps); within noise in both: `tail prompt`, `tail overlap`, `tail overlap waiting`. Since every run spawns its report, until 256 are, almost every sync point has something to apply, and each one settled every tail, so the run waited out the whole body of the benchmark's 4 ms tail ahead of the late one, whose head it had claimed.
+- **A tail reading only its own thread's objects isn't settled at a sync point,** having nothing there a sync point writes: 474 → 12.8 ns.
+- **The benchmark times the run alone,** reading its report after: 12.8 → 9.0 ns. Reading it through `runReported` timed a second run as well.
+
+GPU copies uploading only the chunks CPU writes changed, against `a4eef10e`, chromium, three runs each: new `gpu upload one row 100K`, a target system writing one of 100K 12-byte positions a render system draws, as a drag does, 0.44–0.47 → 0.048–0.058 ms a run; the upload writes the row's chunk of 1,024 rows, 12 KB, rather than the whole 1.2 MB column. New `gpu upload all rows 100K`, a CPU kernel writing every row before the draw, within noise: 5.35–5.55 → 5.24–5.47 ns a row; `observe gpu entity factory` within noise, 0.44–0.51 ms both.
+- **Components a GPU kernel or render system uses keep ticks,** and kernels writing them keep their chunk stamps, though not their row stamps unless a change filter observes them: once per call for a kernel writing every row, a chunk stamp per written row otherwise.
+- **An upload writes each run of adjacent chunks stamped since its last upload** or holding rows a sync point appended or disturbed, clamped to the row count; a column with GPU writes the CPU hasn't read back writes only those rows. A whole-column stamp (`columnChanged`) uploads nothing: only GPU kernels make one, and their writes are on the GPU already.
+- **A WASM kernel's column addresses are kept per load as well as per archetype version:** a kernel loaded again to stamp a component that already kept ticks went on passing the muted column's address, 0, and wrote its stamps over the entity table there.
+
+Render systems with `order`, against `9daaa3f8`, chromium, three runs each: new `gpu ordered render unchanged 50K`, 50K shapes and images, two archetypes interleaved in depth, drawn as one table in a sorted index's order with nothing changed, 0.030–0.036 ms a run, against 0.045–0.049 ms for the same 50K drawn without `order` as two tables, which writes both tables' records each run. New `gpu ordered render one key 50K`, a target system moving one item to another depth and then the ordered draw, 0.268–0.294 ms a run, against 0.042–0.050 ms unordered: listing the 50K entries in order costs 0.167–0.175 ms (3.4 ns an entry) and writing the 200 KB block 0.067–0.070 ms, timed inside the run.
+- **The order block is listed and written only when the index's entries changed or moved rows,** by the index's `changed` tick and a `moved` tick its refresh stamps when it relocates an entry with its key unchanged, or when the matches grew; the tables block only when a column's address changed; the record only when one of its four words did. An unchanged run writes nothing to the queue and allocates nothing: the table, its `bind`, the tables list and the context are reused.
+- **An entry is one u32:** the matching archetype's slot in the high bits, as few as the matches need and at least one, and its row in the rest, so the shader masks by the record's shift.
+
+A 2D editor's first tick after loading a document, against `826c45ad`, node, alternating, three rounds: new `editor load tick 50K` 31.4–33.2 → 20.0–20.4 ms, and `up load` 221–223 → 182–186 ms; within noise: `up depth 10`, `up depth 1000`, `up after a spawn`, `up filtered after churn`, `up filtered after a reparent`, `up small tree in a big world`, `index rebuild 1M main`, `order run 100K`, `order filtered 100K 1%`, `children lookup`, `sorted range 1M`, `sorted page 100K`. The benchmark spawns 50,201 nodes depth first, a document, 200 groups, two subgroups in each and 124 shapes and images in each subgroup, after a first tick over the empty world, then times the next tick: two `up` row systems with `changed` filters writing a position and an opacity, a layout looking up each group's children through a hash index on the parent, and a paint system run in a sorted index's paint order. Before, each system's part of the tick, run alone after the load: the position `up` 13.1 ms, the opacity `up` 10.4, the layout 2.45 (its index's build), the paint 5.43 (its index's build and 50K ordered rows). Of the opacity `up`'s profile, building the tree 22%, marking every row as passing the filters (`changedRows`, `mark`, clearing the marks) 25%, building the order 19%, listing the marked rows from it 10%, and the body 20%. After: 6.4, 4.4, 2.15 and 4.4 ms.
+- **A filtered run after its tree was built again runs the whole order,** as an unfiltered one does, since every row passes then: the tick 32 → 25.1 ms, the position `up` 13.1 → 8.5 and the opacity `up` 10.4 → 7.1. Marking 50K rows, each in a bucket of its depth, and scanning the order for the marks cost as much as the run. A later sparse run is cold for it: `up one root changed` 28 → 33 µs a run over the benchmark's 100 rounds, the marking path no longer warmed by a first full pass, and 14 µs either way after 1,000 rounds.
+- **The tree's build reads each archetype's parent column once,** rather than finding the archetype, column and layout for every entity: the opacity `up` 5.35 → 4.5 ms.
+- **The build sets every level in one walk per entity,** up to a root or an entity already set and back down, rather than settling the entities as journaled changes do, which walk each one's children again: the opacity `up` 4.77 → 4.49 ms.
+- **An order build's scratch is shared by every `up` of a thread:** the second system reuses the first one's arrays rather than allocating its own, 13 of them 50K entries each: the tick 20.6 → 20.0 ms, medians of five rounds.
+- **A sorted index's rebuild skips the sort when its entries are in key order already,** as a load in document order lists them, checked in one pass that stops at the first pair out of order: the paint 5.6–5.8 → 5.1–5.3 ms.
+- **A main-thread system run in an index's order binds its row in place when the archetype changes,** rather than looking the shared row up again, which happens at every row when archetypes interleave in the order: the paint 4.85 → 4.5 ms.
+
+Long hash buckets left unsorted until read by position, against `1ff6c206`, node, alternating, medians of five: new `bucket move 1K/10K/100K length`, one entity moved between the two buckets of an index on a boolean and a run reading both lengths, as toggling a todo is, 9.0 → 5.7, 63.9 → 5.5 and 418 → 5.6 µs a move (two runs' fixed cost included); new `bucket move … in order`, the run reading each bucket's first ten rows, 9.4 → 6.8, 65.2 → 12.7 and 416 → 68.9 µs. Within noise: `index refresh 1M 1%` 159 → 152 ns, `unique lookup 1M`, `children lookup`, `grid neighbors 100K main` and `workers`, `sorted range 1M`, `sorted page 100K`, `order run 100K`, `order filtered 100K 1%`, `index idle`, the keyless and `lookup 1K entities` benchmarks, `index rebuild 1M main` and `workers` (7.74 → 8.19 ms, runs spread 7.2–8.4 both); `rekey 1M` 13.6 → 14.4 ms (+6%), its 10K buckets of 100 taking about six moves each a frame, which a batched merge did in one pass.
+- **A long bucket's change leaves a hole or joins a tail,** found by binary search over the part in entity order or by the tail position kept per entity, so moving an entity costs no shift of the bucket; its record's length counts entries, so `length` and `changed` read no order.
+- **Sorting is lazy where it can be, eager where it must be:** a list's `at` on the world's thread sorts its bucket; `writeIndexParameters` sorts every unsorted bucket before kernels, workers and joined threads read the arrays, since they read entries by position and can't write them.
+- **A sort moves 8-byte words:** shared memory copies an element at a time, a 150K-word `copyWithin` 193 µs as `Int32Array` against 25 as `Float64Array`; a shift by an odd number of words goes through a scratch, 58 µs, once it's at least 1,024 words, the two views of it it makes costing tens of nanoseconds against a microsecond's copy; a shorter one copies a word at a time and allocates nothing. `bucket move 100K in order` 222 → 68 µs; every odd shift a word at a time, 180 µs, and `bucket move 10K in order` 12.7 → 23 µs.
+- **A full unsorted bucket with holes sorts in place rather than moving its segment, and one that grows gets half its length more spare slots:** `rekey 1M` 15.5 → 14.4 ms, from relocated segments, buffer growth and compactions.
+
+Block ticks, alternating against `998738a3`, node, medians of five rounds for the filter benchmarks and three for the rest; chromium, medians of three. New benchmarks (`perftest/filters.ts`), 100K rows of one archetype after a write of one row, ten rows 10,000 apart, or every row, then eight main-thread systems or four WASM kernels filtering on `changed`, timed a run of them:
+
+| Benchmark | Before | Now |
+|---|---|---|
+| `changed one 100K`, eight systems | 34.9 µs | 5.04 µs |
+| `changed few 100K` | 421 µs | 11.5 µs |
+| `changed all 100K` | 8.49 ms | 4.69 ms |
+| `changed one 100K two filters`, the other component unwritten | 37.6 µs | 8.42 µs |
+| `changed one 100K kernels`, four WASM kernels | 5.21 µs | 4.42 µs |
+| `changed few 100K kernels` | 15.2 µs | 7.33 µs |
+| `changed all 100K kernels` | 504 µs | 420 µs |
+| `sparse changed`, 1M, 1% scattered | 354 µs | 317 µs |
+| `sparse changed clustered` | 29.3 µs | 28.0 µs |
+
+In chromium: `sparse changed main` 295 → 260 µs, `sparse changed workers` 70 → 60 µs, `changed few 100K` 115 → 5 µs, `changed one 100K two filters` 40 → 5 µs (timers step by 5 µs), `changed all 100K kernels` 485 → 395 µs. Readers of key and parent ticks: `up one root changed` 27.8 → 26.4 µs, `up filtered after churn` 54.5 → 51.4 µs, `rekey 1M` 13.6 → 12.4 ms, `read run changed` 14.5 → 13.3 µs. Writes within noise in node (`create`, `create flat`, `move`, `churn`, `retag`, `emit`, `emit main`, `reduce`, `chain`, `follow`, `spawn bulk`, `spawn bulk kernel`, `add tag`, `add value`, `add replace`, `despawn bulk`, `index refresh 1M 1%`, `sync point one spawn`, `move 1K`) and chromium (`move`, `chain`, `emit` and `spawn bulk kernel`, main and workers), and so are `run idle`, `run observer`, `index idle`, `observer idle 100`, `joined observer 10K` and `observe gpu entity factory`. Memory: a ticked storage has two block arrays, one for a constant, each 128 bytes per chunk of its capacity, so at least 128 bytes: 1.6% of its row ticks once its capacity is 1024 rows or more, and as much as them at the initial capacity of 16 rows. Each storage's layout record takes two more words.
+
+- **Every row tick's writer raises its block's tick,** one store beside the chunk's: row writes on any thread, kernels (once per call for a block every row of the call reaches, in JS and WASM), the sync point's writes, spawns and moves, swaps into removed rows, a GPU kernel's column stamp lifted onto a joined thread's rows, and joined threads' own ticks. The arrays live in the arena beside the chunk ticks, and the layout directory gives workers and joined threads their offsets.
+- **Main-thread, worker JS and joined-thread filters skip chunks, then blocks, then rows, each in a loop over one array,** and a passing range runs on by row ticks alone until a row doesn't pass; the scan was about 5 ns a row, with a branch per row on the filter count, and is now under 1 ns: `changed all 100K` 8.49 → 4.69 ms.
+- **WASM kernels find runs of passing blocks in an outer loop and run their rows in an inner one,** a chunk's passing blocks read into a mask once and each run found with `ctz`, a chunk with more than half its blocks passing taken as one run; every row pays one comparison against the run's end, where it paid a test of whether it started a chunk: `changed all 100K kernels` 504 → 420 µs.
+- **Index refreshes and `up` find changed key-part and filter rows by blocks too.**
+
+Joined threads' index lookups checking archetypes once a run, alternating against `13eb6d6f`, node, on a machine loaded by other work, medians of 9 and 11 rounds:
+- **A row a lookup gave stays bound while one count stays the same,** as on the world's thread: each flush that writes an existing archetype's record again adds one to a header word, and a joined thread's directory moves its count on once a run when the word, its mirror's archetypes (a rebuild) or its views (memory grown, keys named) changed. Before, every row read loaded its archetype's view, the mirror's entry and the record's version. `joined observer 10K` 485 → 438 µs and 480 → 417 µs a tick; `joined select 10K factory` 524 → 498 µs. Within noise: `joined observer numbers 10K`, `joined observer strings 10K` (their rows bind once per archetype a run either way), `joined observer resource` 4.7 against 4.6 µs, `unique lookup 1M` 79 against 71 ns (its generated site now checks the count, not the archetype's version), `grid neighbors 100K main` 5.94 against 5.99 µs a row.
+- **A rebuilt mirror's rows are bound again:** rows compare the view they were bound to, not only its version, so a row a lookup gave before the thread's log lapped no longer reads the objects of the mirror's old columns.
+
+Runs that wait for nothing allocate no async frame, alternating against `415c463`, node, five rounds, medians: `run idle` 500 → 291 ns, `run observer` 291 → 250, `run 50 idle` 77 → 70 ns a system, `sync point one spawn` 1,000 → 791 ns, `loop tick idle` 1.90 → 1.58 µs, `move 1K` 0.79 → 0.58 ns a row, `despawn one` 1.71 → 1.38 µs, `spawn singles` 323 → 260 ns, `bucket move 10K length` 3.4 → 2.5 µs, `handoff` 13.4 → 11.0 µs, `joined resource factory` 4.3 → 3.6 µs; every other node benchmark within noise but `run failing`, 9.95 → 10.4 µs, its body's error formatting a deeper stack. A run of a system no entity matches allocated 3.4 KB, sampled by the heap profiler, and allocates 0.44 KB: the queue's two promises and the microtasks around them.
+- **The run path is synchronous until something waits:** `perform` runs its steps as plain functions, each going on in an async function of its own only when it has a promise to wait for; `execute` and `executeTiers` run tiers with no GPU, tails, joined threads or observer posts without awaiting, and hand over to `executeFrom` at the first tier on a joined thread, index build across the pool or chunk on workers, settling resumable from where it stopped. Each async function allocated its frame on entry whether or not it awaited: 1 KB for `executeTiers`.
+- **Queuing a run makes no closure:** runs of registered systems wait in reused arrays a shared task takes from in order, and the queue's settle handler is shared.
+- **Functions returning early make no closure context:** `activate` and `prepareSync` return before the part whose closures capture their locals, which V8 allocates on entry; an empty queue isn't spliced, the run's start time is kept in a `Float64Array` rather than passed boxed, and a report's cell is found without an object.
+- **`retag` depends on how it's started:** 50 ms under `pnpm perf`, against 33.7 ms from `node scripts/perf.mjs` or `node dist/perf/run.js` with the same bundle, the base's bundle measuring 33.5–34 run directly; its record here is from `node scripts/perf.mjs`.
+
+Kernels' remainders, alternating against `63552a7`, node, five rounds: new `raise on even ticks 10K`, a WASM kernel testing `resources[clock].tick % 2`, 33.2 → 0.61 ns a row, against 0.51 for `raise 10K` without the test; new `wrap 10K`, a number column `% 1000` in every row, 34.2 → 2.39 ns. Every other kernel benchmark within noise (`move`, `move 10K`, `chain`, `reduce`, `sparse changed`, `follow`). Results stay the body's bit for bit (`precision.test.ts`).
+- **Values the same for every row that call an import are computed once a call:** the largest row-independent expressions holding `%`, `**` or a `Math` function WASM lacks go into locals before the rows. Each row called the JS import, 33 ns from WASM.
+- **A remainder by a nonzero integer literal is exact in WASM while the dividend is an integer below 2^53:** each row checks, and takes the `i64` remainder with the dividend's sign, or the import otherwise.
+
+`up` systems sharing their tree and order, alternating against `940448c`, node, five rounds: `editor load tick 50K` 20.8 → 18.0–19.0 ms (413 → 360–378 ns a node over two sessions), its two `up`s with the same `through` building one tree and one order where each built its own, about 1.5 ms each; every other `up` benchmark within noise (`up depth 10`, `up depth 1000`, `up depth 10 10K`, `up one root changed`, `up after a spawn`, the three `up filtered` ones, `up load`, `up small tree in a big world`).
+- **A thread's `up`s with the same `through` share one tree and order while they agree on every archetype:** whether it matches and whether a parent in it is readable. Each new archetype is checked against every reader, and one disagreeing leaves to build its own. The tree reads the journal once for all, telling each filtered reader the entities whose parents changed, which its next filtered run marks and a whole pass drops; a reader holding more than a journal's worth drops them and runs every row next. Each keeps its own marks and lists. Within noise of that, against `198cb74`: `editor load tick 50K`, `up filtered 4K, 250 moving a frame`, `run idle`, `run observer`, `loop tick idle`, the `up filtered` ones.
+
+The journal keeping its newer half when full, alternating against `45ce602`, node, five rounds: new `up filtered 4K, 250 moving a frame` 110 → 97 µs a frame. It dropped every entry once full, within a sync point too, so readers current at the last one, `up` trees and indexes, built again every four to five frames there, and a filtered `up` then ran every row; a test counts the rows it runs. Within noise: `index refresh 1M 1%`, `rekey 1M`, `keyless refresh 1M 1%`, `keyless spawn 1M 1%`, `bucket move 10K length`, `up filtered after churn`, `up one root changed`, `churn`, `editor load tick 50K`, `order filtered 100K 1%`.
+
+`transfer` in chromium varies with the bitmaps it moves, not the ECS: of its ten batches of ten transfers, each 1024 by 1024 bitmap and 1 MB buffer, a batch takes about 0.8 ms or about 2 ms, in either order, so the sum of ten ran 13.3–21.6 ms over six runs; with 1 by 1 bitmaps the batches are unimodal (medians 0.42–0.64 ms) and new `transfer small bitmaps`, the fastest of 40 batches for 100 transfers, ran 2.65–3.3 ms after its first run. Waiting 30 ms before each batch made both modes slower, cores clocking down while idle, and warming the threads with four tiny transfers first left the two modes as they were.
+
+`index rebuild 1M workers` had measured the world's thread alone, 27–29 ms in node and chromium, since its pool-starting kernel matched no row and the pool now starts only for kernels over rows enough for workers; its kernel runs over the 1M keyed rows instead: 6.6–7.0 ms in node and 7.9 ms in chromium, as recorded before.
+
+Runs without reports, alternating against `225fd64`, node, three rounds each, the fastest run: `run idle` 291 → 208 ns, `run observer` 208–250 → 125, `run failing` 10.3 → 6.7–6.9 µs, `loop tick idle` 1.60–1.65 → 1.47–1.54 µs a tick; within noise: `run 50 idle`, `read run`, `read run observer`, `read run changed`. The fastest run steps by 42 ns there, so a mean of 200K runs, three rounds: `run idle` 365–371 → 274–277 ns, `run observer` 300–317 → 212–215.
+- **A run spawns, writes and stamps nothing of its own,** and reads no clock: no entity per run, no `Report.run` struct, no `elapsed`, no errors added or removed between runs, and no wait for tails before a tick's observer systems.
+- **A failing run builds its Error once its sync point and observer pass are done,** from failures gathered as data, and rejects; nothing is queued for a sync point of its own.
+- **The queue chains a promise of its own, which never rejects,** a failure carried as a value, and gives each run a second promise, which nothing in the queue handles, so a failing run nobody awaits is an unhandled rejection whatever follows it. Making each run's promise the queue's tail, one promise a run, was 25–35 ns faster (`run idle` 247–256 ns and `run observer` 187–194, means of 200K runs, against 282–288 and 221–224 now; `loop tick idle` 1.49–1.52 µs against 1.56–1.59), but the next run's handler swallowed a failing run nobody awaited: correctness outranks the cost, which a later measurement put at 42 ns on `run idle`. A queue settling each run through `Promise.withResolvers` cost more again: 295–312 and 232–252 ns.
+
+Shared components and `where`, against `12e366d`, node: the whole suite three times on each, then the key benchmarks alternating, five rounds; every one within noise (fastest runs, before → after): `run idle` 208 → 208 ns, `run 50 idle` 68.3–69.2 → 68.3–70.8 ns a system, `run observer` 125 → 125 ns, `loop tick idle` 1.55–1.66 → 1.48–1.57 µs, `move 1K` 0.50–0.54 → 0.50–0.54 ns a row, `churn` 16.0–16.6 → 16.0–16.6 ns, `spawn singles` 240–250 → 240–250 ns, `spawn bulk` 25.3–25.7 → 25.3–25.7 ns, `sync point one spawn` 667–750 → 708 ns, `add tag` 93.6–95.7 → 94.4–96.8 ns, `remove tag` 70.0–71.0 → 70.0–71.2 ns, `index idle` 9.4–9.7 → 9.2–9.8 ns, `index refresh 1M 1%` 144–149 → 142–150 ns, `unique lookup 1M` 44.7–46.5 → 44.2–47.1 ns, `sorted range 1M` 656–662 → 656–679 ns, `keyless index idle` 7.0–7.3 → 7.0–8.0 ns, `move` 0.36–0.38 → 0.36–0.38 ns, `chain` 0.256–0.264 → 0.256–0.264 ns, `with 100K kernel` 0.49–0.51 → 0.50 ns, `changed one 100K kernels` 1.07–1.20 → 1.10–1.23 µs, `struct replace kernel main` 61.6–65.0 → 63.8–66.2 ns, `editor load tick 50K` 361–386 → 351–370 ns a node, `remote run` 8.8–11.9 → 9.0–11.9 µs, `handoff` 10.9–12.2 → 10.4–12.3 µs, `fused tiers` 6.5–7.4 → 6.4–6.9 µs, `joined observer resource` 3.4–4.2 → 3.3–3.7 µs, `joined observer 10K` 0.41–0.48 → 0.42–0.48 ms, `tail prompt` 16.6–17.9 → 16.6–17.7 µs, `observer idle 100` 76–85 → 83–86 ns. In chromium, three suites alternating with the baseline's, every benchmark within its noise (such as `move workers` 0.06 → 0.06 ns a row, `loop tick idle` 3.90 → 4.04 µs with 3.2% noise, `tail prompt` 22.5 → 21.3 µs). Worlds and archetypes without shared components look archetypes up, take their edges and bind rows as before: the world's `sharing` flag and each component's entry in `State.shared` stand in front of everything new.
+- **A shared value read in a row costs what a column's does:** `shared read 100K` 4.04–4.10 ns a row against 4.24–4.27 for `column read 100K`, the value bound with the row once per archetype. In a kernel it's a parameter of each call: `shared read 100K kernel` 0.40–0.41 against 0.50 for `column read 100K kernel`, one column fewer to stream.
+- **Spawning with a shared constant:** `spawn bulk shared`, one spawner reused, 17.3–18.1 ns a spawn against 33.3–34.3 for `spawn bulk plain`, whose cell is a column; `spawn singles shared`, its spawner found by its constants each call, 313–323 ns against 229 for `spawn singles plain`: about 90 ns a call to find the spawner, a tuple's leaves walked through a tree of its stored leaves (`shared.ts`) and each constant in turn through the shape's tree of spawners, with no text built.
+- **`where` over 1K cells,** 3 × 3 of them in view: `where 1K cells still` 0.49 ns a cell, 0.5 µs a run with nothing evaluated; `where 1K cells moving`, every predicate evaluated again as the camera moves each run, 18.7–19.0 ns a cell, each predicate's resources read once per evaluation.
+- **Many small archetypes:** `small archetypes 1K`, 10K rows over 1K archetypes of one cell each, 7.26–7.43 ns a row against 3.46–3.49 for `one archetype 10K`: about 39 ns an archetype, binding its row and walking its filters, which a shared component's values multiply.
+
+Review fixes to shared components and `where`, node, alternating against the commit before each, medians of four to six rounds:
+- **Arrivals precise** (`arrivals.ts`): a system with `where` and change filters reads a ring of the moves since its last run, each archetype moved into owing the point of the one its rows came from, where every arrival made the archetype count from the oldest point of all matches, found by a scan of them. New `where changed 1K cells drifting in view`, every cell in view, 1% of 10K rows moving to the next cell before each run: 123.6 → 69.2 ns a cell; `where changed 1K cells drifting`, 3 × 3 cells in view, 2.0 → 2.8 ns a cell, the ring's 102 entries a run read, about 7 ns each, and cells moved into from culled ones scanned since that one's point; `changed 1K cells drifting`, without `where`, 52.3 → 52.0. `where 1K cells still` and `moving` within noise.
+- **`commands.spawn` takes its constants as a second parameter,** where a rest parameter allocated an array every call: `create` (1M spawns, no shared components) +4.1% → +1.4–1.8% against `12e366d`, within the ±2% the suite moves from session to session; bisected over the shared components' commits, no other step stood out. `joined observer 10K` and `tail prompt` within noise in node (+0.3%, +1.2%, rounds spreading 5–20%) and in chromium (+1.7% over 237–360 µs, −9%), eight rounds against `12e366d`.
+- **On the GPU, a shared f32 value** read and stored, an integer leaf, and one product, sum or difference of f32s are the body's bit for bit; longer arithmetic rounds each step in f32 where JS rounds once at the store: `value * scale / 3 + scale * scale` over scales 0.1, 1.7 and −3.3 differs by at most 1.65e-7 of its largest term, up to 14 ULPs of a result near cancellation (`shared-gpu.browser.test.ts`, bound 2^-21).
+- **A spawner's guard** against a component given in both calls, one check of each constant's key a spawn: `spawn singles shared` 323 → 323 ns, `spawn bulk shared` 18.0 → 18.1 ns.
+- **Reclaiming** (`reclaim.ts`): an entity walking one cell a run made an archetype, an interned value, a batch and spawner levels per cell, for good: after 20K cells 20,002 archetypes, 185 MB of heap and 9.1 MB of arena, and `one row after 100K cells walked`, a system over one row, 2.76 ms a run against 250 ns before the walk. Reclaimed and reused, after 100K cells: 11 archetypes, 9 values, 9 batches, 18 spawner levels, heap 29.7–29.9 MB from 1K cells on, arena 71,616 B throughout; `one row after 100K cells walked` 250 ns; `walk to a new cell` 10.3 → 2.8 µs a run. Waiting out empty sync points (`emptyFor`), `circle 8 cells`, round 8 cells, each emptied 7 sync points: 2.67–2.69 µs a run at 1, 2 and 4, reclaiming and reusing one archetype a run, 1.00 at 8 and 16, reclaiming nothing; `walk to a new cell` 2.69–2.73 µs at 1 to 4, 2.81 at 8, 3.06 at 16, scanning more candidates; `flicker between 2 cells` 958 ns at all, against 916 before reclaiming, the sync point's scan of its emptied archetypes. 8, so a cell left for up to 7 sync points keeps its archetype. Edges cached to an archetype of shared values are kept on it to clear, but a batch's archetype is checked by its generation instead: an edge object per spawned archetype, allocated between archetypes and their storages, made `where 1K cells moving` 10% slower, its 1K predicates walking archetypes spread over more memory; checked, +1.8%. Worlds without shared components, five rounds against the commit before: within noise (`run idle` 208 → 208 ns, `run observer` 125 → 125, `loop tick idle`, `move 1K`, `main thread 1K`, `sync point one spawn` 708 → 708, `create` +0.5%, `create flat`, `spawn bulk`, `despawn one`, `churn`, `add value`, `remote run`, `joined observer resource`, `joined observer 10K`, `handoff`, `tail prompt` +0.5% over eight rounds, `log replay`, `read run`); `run 50 idle` was +5% a system until the run's check for reclaimed archetypes kept the scan for new ones apart, out of what its runner inlines: 71.2 → 71.2 ns.
+
+## Where the gains came from
+
+Step figures marked (vitest) are from the node vitest lane: read them as relative.
+
+**Structural changes.**
+- Commands as parallel typed arrays, a reusable typed plan, and cached archetype edges: create 198 → 68 ms, churn 22 → 10 ms, retag 24 → 11.7 ms, emit 7.3 → 3.1 ms (vitest).
+- `Object.keys` instead of `for…in`, and buffers reused across runs: small gains.
+- Allocation-free kernel commands (`begin`/`value`/`component`/`spawn`): emit 3.2 → 1.98 ms (vitest).
+- Kernel commands write the buffer themselves, not through `pushCommand` and `pushComponent`: once V8 reoptimized a
+  kernel, the second call stayed a call and boxed each entity, a double past 2^32. `despawn bulk kernel` 4.60 → 4.12 ms;
+  `despawn bulk` compiled 4.55 ms against 4.32 as written before, 4.10 after.
+- Inline value writes instead of closures, an 8-shape spawn cache, edges indexed by component id, archetypes grown once per sync point: create 38 → 27.6 ms.
+
+**Change filters.**
+- Chunk ticks, the newest tick per 1024 rows, so filters skip unchanged chunks: clustered sparse to ~0.09 ms.
+- Block ticks, the newest tick per 64 rows, so filters skip a changed chunk's unchanged blocks: eight systems finding one changed row of 100K 34.9 → 5.04 µs (above).
+- Filters inside WASM kernels, one call per archetype instead of one per passing range: uniform sparse 3.5 → 1.15 ms, clustered to 0.02 ms.
+
+**Lookups.**
+- Precompiled matchers with component ids resolved once: follow 10.4 → 4.8 ms.
+- Lookups in WASM through a directory per lookup in shared memory: follow 4.8 → 0.37 ms. Exact entity decoding costs about 0.07 ms, partly recovered by an integer fast path.
+
+**Kernel hot path.**
+- Full 16-byte loads for three-lane rows: move 0.262 → 0.204 ms.
+- Four rows of whole interleaved elements as full vectors (three for tight vec3) instead of one partial vector per row: move 0.177 → 0.095 ms, chain 6×1M 3.5 → 1.55 ms, chromium main thread move 0.200 → 0.105 ms.
+- `changed` stamps only for observed components: move 0.204 → 0.175 ms, chain 0.47 → 0.344 ms.
+- Tick columns only for components some system filters on, started at the current tick when the first one registers: create 1M 325 → 296 ms, retag 1M 79 → 68 ms, churn 1M 54 → 50 ms. For the particle fixture, ticks were 80 of 112 bytes per entity.
+- Exact integer `%` in WASM instead of a JS import.
+
+**Dispatch.** A task ring per worker in shared memory with `Atomics.notify`, and fast kernels split at half the minimum chunk: chain on workers 0.485 → 0.255 ms, then 0.16 ms with the kernel gains.
+
+**Claimed splits.** Workers claim pieces of a WASM kernel's rows from a shared counter instead of taking even shares, so the slowest core no longer sets the finish time: on the default pool, move 0.055 → 0.030 ms, follow 0.15 → 0.075 ms, chain 0.16 → 0.115 ms, sparse changed 0.30 → ~0.22 ms.
+
+**Affinity claims.** Each worker owns a home range of a split's pieces, the same one every run, takes them from the front, and steals from the back of the fullest other range once its own is empty. Pieces stay on the same worker from one tier to the next 75% of the time instead of 13% (no better than chance), so tier N+1 finds its rows in the cache tier N warmed: chain 6×1M on workers 0.79–0.87 → 0.275 ms, per tier 230 → 170 µs in traced medians; move 1M on workers 0.020 → 0.015 ms. Control words, claim words and status slots each take whole 128-byte cache lines, so a store by one thread doesn't invalidate the line another polls.
+
+**Staged spawns.** A main-thread `commands.spawn` writes its values into a private batch per component set, in the target archetype's layout, and the sync point block-copies each batch into its archetype before the plan, placing entities and stamping ticks with the sync tick. The issuer's tuples are read while fresh and die young, and the plan, shape match and per-component writes at the sync point go away: create 1M 300 → 153 ms, churn 29 → 21 ms. The plugin rewrites each `commands.spawn({ ... })` with literal keys in a main-thread system into a per-site function taking one parameter per value, so no value object is built, nothing is looked up by key, and each value goes through a writer specialized once per shape to its column's layout, called only from that site: create 1M 153 → 88 ms, flat 181 → 70 ms, with no code generated at runtime. adobe/data's ecs2 inserts the flat particles at about 57 ns each, immediately and without deferral, after building each value object. Spawns of objects built beforehand read values by key in a loop, about 3× slower.
+
+**Structs.** A struct's read and write, and a nested tuple's, are generated per layout as straight-line code: one literal of its leaves' loads, and one store per leaf, where a closure per leaf built the object a property at a time and read each member through `Reflect.get`. Where `'unsafe-eval'` is forbidden the closures run. `struct copy 100K`, a main-thread row system copying a five-number struct, 147 → 17.6 ns a row in node and 20.4 in chromium; `struct replace kernel main`, a struct and a vec2 added per row as commands, 144 → 118 ns a command. A command of an entity following its previous one in the same buffer, as a body's adds to one row do, extends that one's range of values rather than listing another range in a map: 118 → 60.9 ns, 70 in chromium, 61 on chromium's workers.
+
+**Change sets.** An entry between the same archetypes as the one before it, whose one range of values names the same components, joins that one's group without listing its replaced components or building a group key, as one system's commands over one archetype make: `struct replace kernel watched`, a changes finalizer watching 200K replacing adds, 187 → 76.8 ns a command, against 63.6 unwatched.
+
+**Joined threads.** A wake notifies only a joined thread that has read every earlier one, by a word the thread clears before it reads what's new, so back-to-back ticks don't notify a thread still busy with the last. A wake landing between the thread's clearing the word and its wait notified no one, and the word then kept later wakes from notifying, so a reader there fell behind and stopped being woken (4,412 of some 6,000 values seen); with the thread reading again while the word is set, it sees every value.
+
+**Structure epoch.** Kept only while a joined thread holds claims, turned even by a store and notifying only a reader that waits: `sync point one spawn` 916 → 833–875 ns in node, measured alternating with `c4ecbd8d`, from before phase 4, at 833–875 ns. Two atomic adds and a notify cost about 35 ns a sync point, an add and a store about 24 ns.
+
+**Joined threads' objects.** A rebuild fills each column with its start first and indexes the old rows by entity only for a value the thread gave and kept: `log rebuild 100K` 9.7 → 4.1–4.8 ns a row in node. Their ticks are the world's storages' alone, which the thread's systems stamp, rather than copies the mirror kept beside its columns: `log replay` 24 → 20.6 ns a move and `log rebuild 100K` 4.31 → 3.21 ns a row in node, 5.3 → 3.45 in chromium.
+
+**Systems on joined threads.** A tier, or consecutive tiers, on a joined thread is a task through its task block. The world spins about 20 µs for it before it waits, and the thread that finished one spins as long for the next, each about one wake-up's latency: `handoff` (five tasks a tick) 68 → 11.5 µs a tick and `fused tiers` (one) 19.3 → 7.5 µs in node, 13.2 and 9.4 µs in chromium. Ten tiers fused into one task cost about what one tier's does.
+
+**Finalizers on joined threads.** Stop lists are written a column at a time, the linear structs copied by 32-bit word and each column's storage found once per run of an archetype, and despawned entities' held indexes counted in an array by index: `despawn objects 10K` 176 → 83 ns a despawn in node, against 77 ns with the same finalizer run inline on the world's thread. A `Map` of holds, and a `copyWithin` per stop and struct, cost most of the difference.
+
+**Tails.** A tail's snapshot is laid out for the rows it found passing and copied a run of consecutive rows at a time, its entities and each linear read one `set` each, its positions, archetypes and rows written in place, and tags marked only for a tail that writes objects: `tail late snapshot 10K` 29.8 → 6.7 ns a row in node, from a row at a time through a scratch list, whose tag pass alone cost 3.3 ns a row for a tail that writes nothing. The copy is what lets the world's work after its writer overlap a late tail: `tail overlap` 2.53 ms a tick against 4.70 for `tail overlap waiting` in node (below).
+
+**Indexes.** Node numbers, `pnpm perf`.
+- Keeping one current costs nothing while its entities rest: a refresh checks its journal position and its key parts' last writes, which systems' writes and sync points' values mark per component, `index idle` 9 ns an index. Moving 1% of 1M entities to other keys, `index refresh 1M 1%`, 4.3 → 1.56 ms: rows listed with their archetype and row, without marks when one key part's scan is all a refresh reads, short buckets' operations applied as they come and long ones left unsorted; a refresh whose changed chunks' rows pass an eighth counts the rows' own ticks before building again, so a few writes spread over every chunk patch: `rekey 1M`, 1M particles 6% of which cross into another cell a frame, 46.9 → 14.1 ms, against 4.8 ms for the same frame without the index.
+- Lookups: a call site's encoding, hash and probe generated for its shape and the index's layout, buckets as records of hash, segment and key beside two-word slots of hash and bucket, and a row bound only when its archetype changed: `unique lookup 1M` 86 → 45–50 ns. A microbenchmark of the same probes over the same table reads 29 ns sequential and 85 random a lookup; an identity hash for integer keys is under "Tried and not kept". `children lookup` 32 ns a child, `grid neighbors 100K main` 10.5 µs a row of 27 probes.
+- Sorted ranges: a search over a compact array of each block's last key and entity, comparing words only for keys of words, and `at` walking blocks through a cursor: `sorted range 1M` 1.08 → 0.76 µs a range of ten; `sorted page 100K` 22 µs a change against 1.12 ms for `select page 100K`.
+- Kernels: probes in straight-line WASM over the index's arrays, `grid neighbors 100K workers` 179 ns a row across nine workers.
+- Building again in phases over fixed pieces and partitions, the listing generated for the key's leaves: `index rebuild 1M main` 37 → 27.3 ms on the world's thread alone, and 6.7 ms across nine workers, the four phases about 1.3, 1.9, 1.3 and 1.8 ms. One worker takes 29 ms, so nine scale it 4.3×: each phase scatters or gathers by partition, and a single-threaded microbenchmark of grouping alone runs at 4.8 ns an entry, branch and memory bound.
+- `order run 100K` 31.4 ns a row against 28.3 for the same body in storage order: main-thread bodies walk the index's entries, bound again where the archetype changes, rather than listing rows first (34.5 ns). `order filtered 100K 1%` 180 ns a changed row.
+- Lists and their rows of one hidden class: lists defined their accessors as an object literal's, new closures each, so every list after a site's first had dictionary properties, and each pooled row had a map of its own, so a body reading a bucket was megamorphic. Lists and rows now define shared functions in the same order and read their state through `this`; a lookup makes its pool's rows ahead of `at`, the first 256 positions and, for sorted lists, the last 256, so one-time work stays out of what a body inlines and the row getters fit its budget; on the world's thread a row checks one count of replaced arrays, not its archetype's version. `grid neighbors 100K main` 10.6 → 3.66 µs a row, `children lookup` 32 → 13.1 ns a child, `sorted page 100K` 22 → 5.0 µs a change, `sorted range 1M` 760 → 563 ns a range. What's left in `grid neighbors 100K main`, against about 1.6 µs for the kernel on one worker: its 27 probes, 24 of which miss, about 0.7 µs at a half-full table (2.4 slots a probe; a JS microbenchmark of the same probes takes 0.51 µs), and about 6 ns an `at` and 4 a read for each of its 260 neighbors, the loads of the list's state, the pool and the row's slots that TurboFan doesn't hoist out of the loop.
+- Refreshes: a refresh lists changed rows once, building again when they pass an eighth, rather than counting their ticks first and scanning again; entries shift an entry a step; whether a key holds objects is kept, not scanned for per entity: `index refresh 1M 1%` 165 → 141 ns a moved entity, `rekey 1M` 14.5 → 12.3 ms. With 100K entities, all in cache, a move still takes 145 ns, so it isn't memory bound: two ordered edits, a binary search and a shift in the old bucket and the new, take 57 ns in a microbenchmark, and finding the key's bucket and the per-entity bookkeeping the rest.
+- Indexes without a key, kept as sorted tables with no key words: `keyless refresh 1M 1%`, 1% of 1M entities spread through entity order leaving or entering again, 343 → 187 ns an entity, from padding entries to four words, so a block's shift moves 8-byte words, which a copy within shared memory moves about five times faster than 4-byte ones (a 1.8 KB shift 622 ns by 12 bytes, 128 by 16; a loop is no faster), and binary searches by entity within a block; what's left is a shift of about half a block and a search over 10K fences each way. `keyless spawn 1M 1%`, 1% despawned and spawned again at the end of entity order, 22.4 → 2.1 ms: a split or dropped block refreshed every position, fence, Fenwick node and segment tree, and now those from its position on. `keyless length` 60 → 4.8 ns a lookup reading `length` and `changed`: a site without arguments copies no values, the plugin's count-0 site calls it directly, and a whole index's `changed` reads its tree's root rather than two Fenwick descents. `keyless write 1M`, a refresh after a kernel wrote a component all 1M hold, 3.6 µs, as `keyless index idle`'s 7 ns an index: it reads no key ticks.
+- `unique lookup 1M` stays at 44 ns: a build numbers buckets by slot partition, so a lookup in key order reads its slot, record and entry at three unrelated places; a JS microbenchmark of that chain takes 58 ns, and of the slot probe alone 17.8.
+
+**Hot helpers kept small.** TurboFan inlines what a system's body calls into its runner's loop up to a cumulative bytecode budget, so what's left for the row getters depends on everything else the body reaches. `pushCommand`'s growth, a prepared spawn site's plan lookup past the one kept by archetype index, and a list's shape and spawner past the cached ones are outlined: churn 15 → 18 ms in node had come from code elsewhere in the bundle, a dead function placed before `finalizers.ts`'s runner reproducing it on `fe36a99f`, and with `--max-inlined-bytecode-size-cumulative=2000` both measured 14 ms; outlined, churn is 14.9 ms on `fe36a99f` and 15.0 ms here.
+
+**Archetype moves.** Each storage knows its element size in 32-bit words, so a cell copy doesn't dispatch on the layout, and move lists are cached in an array by target archetype id rather than a map: retag 1M 46.5–48.8 → 41.8–44.2 ms.
+
+**Main thread.** Row getters chosen once, and tuple reads and writes in one loop: 50 systems 3.2 → 1.63 ms (vitest).
+- Accessor rows each get their own prototype. Built from `{}`, every row after the first that defines an accessor with another getter went to V8 dictionary properties. One row per set of reads and writes, shared across systems and archetypes and rebound per pass, so a body sees one shape; f32-lane tuples read as array literals, and scalars and f32 lanes written directly. Resource cells in a context are resolved once per run. On node: 50 systems 1.1 → 0.45 ms, churn 55 → 32 ms, retag 74 → 59 ms; 50 distinct bodies over three row shapes 1.75 → 0.53 ms; two writing systems over 100K 19.5 → 1.9 ms; 20 systems reading a resource per row 1.26 → 0.22 ms.
+
+**f64 lanes for kernels computing at the body's precision.** A kernel compiled without `kernel: true` computes in f64, as its body does, so it can't use f32 lanes. Across rows it runs f64x2 lanes instead: each f32 pair loaded with `load64_zero` and promoted, each operation the f64 one, demoted only on store, so results are the body's bit for bit (`wasm.test.ts`, `precision.test.ts`). Medians of five, node, against one row at a time in f64 and against `kernel: true`'s f32 lanes: `move` 0.399 → 0.177 ms (f32 lanes 0.090), `chain` 6.48 → 3.70 ms (1.55), `move 10K` 16.2 → 7.7 µs (4.5). Filtered kernels and reductions run a row at a time in both, so `sparse changed` and `reduce` are unchanged; a padded vec3's elements aren't whole vectors, so it does too.
+
+## GPU particles
+
+The sample (`pnpm dev`, the GPU Particles tab, or `/particles/` alone) draws the visible and enabled quarter of the perf particles as points, wrapping positions in the vertex shader, and moves them with the perf `move` kernel: on the GPU (`?mode=gpu`, positions never come back), on workers with the positions uploaded for drawing each frame (`?mode=cpu`), or not at all (`?mode=static`). Headless chromium on Apple silicon at 60 fps, 10 s per sample after warmup, CPU time per frame by process from `ps`, main-thread task time from the DevTools protocol. Four rounds at 1M (250K drawn), two at 4M (1M drawn):
+
+| Per frame, ms | draw only | CPU move + upload | GPU move |
+|---|---|---|---|
+| `run`, median (p95), 1M | 0.28 (0.6) | 0.75 (3.9) | 0.39 (0.75) |
+| main thread busy, 1M | 0.95 | 1.9 | 1.02 |
+| renderer process CPU, main thread and workers, 1M | 2.2 | 4.9 | 2.3 |
+| GPU process CPU, 1M | 2.9–3.0 | 2.2 | 3.1 |
+| `run`, median (p95), 4M | 0.2–0.45 | 0.97 (1.9) | 0.40–0.46 (0.87) |
+| renderer process CPU, 4M | 1.5–2.7 | 5.55 | 2.6 |
+| GPU process CPU, 4M | 2.0–3.3 | 4.2 | 3.2–3.3 |
+
+- **The GPU move costs about what drawing alone does:** about 0.1 ms more `run` and 0.1 ms more renderer CPU, the same at 250K and 1M drawn: one record write and one dispatch per archetype.
+- **The CPU move costs about 2.7 ms more renderer CPU per frame and twice the main-thread time,** though the move itself is 0.015–0.03 ms on workers. The rest is waking workers inside a frame loop and the 3 MB (12 MB at 4M) upload, copied on the main thread by `writeBuffer` and again in the GPU process, whose CPU rises at 4M.
+- **The GPU process uses less CPU in the CPU mode at 1M** than with nothing moving at all; not understood yet.
+
+## Worker scaling
+
+move, chromium, by worker count and entity count (a quarter of the entities move), with even shares:
+
+| Workers | 1M | 4M | 10M |
+|---|---|---|---|
+| 0 (main thread) | 0.200 ms | 0.785 ms | 1.98 ms |
+| 1 | 0.195 ms | 0.785 ms | 1.97 ms |
+| 2 | 0.100 ms | 0.410 ms | 1.01 ms |
+| 4 | 0.045 ms | 0.215 ms | 0.535 ms |
+| 6 | 0.030 ms | | 0.500 ms |
+| 7 | 0.025 ms | 0.150 ms | 0.56 ms |
+| 8 | 0.060 ms | | 0.555 ms |
+| 9 (default) | 0.055 ms | | 0.575 ms |
+
+- **Dispatch overhead is not the limit.** Scaling is linear up to 7 workers at 1M: 0.025 ms is 8× the main thread and 3.6× the adobe/data ECS.
+- **Even shares wait for the slowest core.** The default pool is `hardwareConcurrency − 1`, which is 9 here. Past 7 workers, shares land on efficiency cores or share a core with the main thread, so 1M more than doubles. Browsers expose no core types or thread placement, so claimed splits fix this instead: with them, 1M takes 0.030 ms at 7, 8 and the default 9 workers. Pieces per worker (4, 8 or 16) made no measurable difference.
+- **At 10M the work is memory bound.** 2.5M rows read 24 bytes and write 12, about 90 MB per run; 0.5 ms is about 180 GB/s, near the chip's CPU bandwidth. It stops improving after 4 to 6 workers, and more entities would not change that.
+- **Single-threaded move matches the adobe/data ECS** (0.095 ms against 0.09 ms): four tight vec3 rows are three full vectors, as its separate x, y and z arrays are.
+
+## Tried and not kept
+
+- **Shared components' runs through one loop with `where`'s,** the run list a match list or `where`'s passing one: `run 50 idle` 68.3–69.2 → 75.8–79.2 ns a system, the run's closure grown past what V8 inlines. Kept: `where`'s loop apart from the plain one, which runs as before: 68.3–70.8. Worth revisiting if the two loops grow apart in what they do.
+- **A shared value read through its storage's layout on every row,** `layout.kind === "constant" ? layout.value : …`, so copies of rows across archetypes could hold values by row: `shared read 100K` 5.37 ns a row against 4.20 for `column read 100K`. Kept: the value bound into the row's slot once per archetype, 4.04–4.10, and snapshots and stop lists bound a run of one archetype's rows at a time, each archetype its own copy.
+- **Interning every shared value by its canonical text,** a tuple of numbers included: `spawn singles shared` 604 ns a spawn against 229 for `spawn singles plain`, the text built and the value checked against its schema for every spawner looked up. Kept: tuples of numbers found through a tree of their stored leaves, 313–323. Worth revisiting for structs and strings once a workload looks up spawners of them often.
+- **`where`'s predicates reading resources through a system's context,** each read copying a struct out: `where 1K cells moving` 25.9 ns a cell against 18.7–19.0 reading each once per evaluation.
+
+- **Checking every row and render body's return through a function call,** to fail a system whose body returned a
+  promise: `churn` 15.9 → 18.6–19.2 ns a row, a call per row. Kept instead: the call only for a body that returned
+  something, after an inline `!== undefined`, which measured the same as no check (`churn` 15.8–16.3 ns against
+  15.8–16.2). Worth revisiting only if bodies commonly return values.
+
+- **Lists made at runtime finding their shape through a `WeakMap` by list, or through a record of their own beside the
+  index property:** with `Archetype.create` gone, `spawn sixteen archetypes`, whose lists are built by `Array.from`,
+  took 9.8 ms and 6.9 ms against 3.96 with them indexed by hand; a microbenchmark gave 43 ns a lookup for the second
+  property against 5.4 for an index. The record now lives in the index property itself, 12 ns checked: 4.37 ms, the
+  rest the check of the list's keys that a list made at runtime needs, since it may change. Worth revisiting if a way
+  to know a runtime list is unchanged without reading its keys appears.
+- **Observer posts without allocating per post** (a reused list of chosen posts, no closure for posting, the block's cleared words a constant list, settling over reused scratch rather than a copy of the posts): `joined observer resource` 7.2–7.6 µs a tick against 6.4–8.3 without, `joined observer 10K` 0.52–0.69 ms against 0.51–0.76, within noise. Worth revisiting once posting shows in a profile of a world with many observer systems on joined threads.
+- **Observer factories: a count or selection with `where` tracked through an index without a key,** every row read through `at` and tested after any change: `count 1M changed factory` 23.2 ms; a sorted index on the `where` key, each entry looking up its range, takes 42 µs. Kept for selections with a page and no `order`, which stop at the page's end in entity order.
+- **Observer factories: descending pages finding each run of equal keys by galloping back from its last row,** three reads of most rows: `select page 100K factory` 23 µs a change; reading each row once, holding a run until its key changes, 16 µs.
+- **Observer factories: a scan's result copied out of scratch,** `select factory` 14.3 ms; gathered into the value itself, with the test inline for one entry and entity indexes by `>>> 0`, 10.3 ms. What's left is a row body a row; worth revisiting with a way to read columns in an observer system without a body call per row.
+- **Observer factories: keeping a resource's notifier added once idle,** a cold read 2.6 µs (a run of the reader alone) against 14.0 µs adding it again, nearly all of it registering its runner; kept removing it after three idle passes, since each added notifier costs every pass. Adding an observer system again now reuses its runner (0.1 µs of a 0.88 µs cold read), so removing stays.
+- **Observer factories: a direct scan's numeric condition tested inline,** its range's bounds compared in the body rather than through the condition's test: `select factory` 8.55 ms against 7.55, the larger body costing more than the call it saves.
+- **Observer factories: gathering every entity into a plain array, its value a slice,** 9.5–9.65 ms against 9.1 for typed scratch copied into an array made at its length.
+- **One block for posts holding copies, the next post waiting for one in progress:** back to back the world waited for the thread's run in 1,696 of 20,000 ticks, about 10 µs each after a 5.6 µs spin, 1.3 µs a tick; a second block, which the next post goes into while the thread runs one, removes the waits. Worth revisiting only if a block's memory mattered.
+- **The cadence benchmarks giving the median tick, or the median of ten stretches of 100:** chromium's timer steps are as long as a tick, so its median tick was 20, 25 or 30 µs; a stretch's mean holds its slowest ticks, 25–113 µs a tick on a loaded machine against 18–40 for the mean of the middle half of the ticks.
+- **An observer system on a joined thread whose unclaimed post a writer cancels rather than copies:** `joined observer resource` 6.0–6.3 µs a tick against 6.2–6.6 copying, within noise; kept copying, since a thread that claims between the writer and the sync point then still runs. Worth revisiting if copying a large read set per tick shows in a profile.
+- **Waiting for the post after one cancelled (`cancelsBeforeWaiting` 1), or after sixteen:** at 1 the thread runs at least every other sync point, but the world waits for its wake-up nearly every other tick back to back: `joined observer resource` 11.4–15.8 µs in chromium against 9.3 at 4, `joined observer 10K` 0.50 ms in node against 0.30. At 16, 6.4 µs and 0.11 ms in node, 9.2 µs and 0.12 ms in chromium, the thread up to 17 sync points behind. Without waiting at all, `joined observer 10K` never ran in chromium in 3,000 back-to-back ticks: every post was cancelled first. Kept 4. Worth revisiting with a cadence-aware limit, such as milliseconds behind rather than posts.
+
+- **A loop spawner as the only spawner:** about twice the generated one (numbers above). Kept only where code can't be generated. Worth revisiting if engines specialize a shared loop's keyed reads per shape.
+- **Prepared spawn sites calling the shape's column writers:** one site spawning into four archetypes made each writer call see four closures, `create` 103 ns and `create flat` 76 ns, against 58 and 66 ns through a positional spawner generated per site key order and shape.
+- **Removing the prepared sites,** as the plan for curried spawns proposed once they no longer won: they still win by the values object's cost (above).
+- **A spawn site remembering the last archetype and world it spawned into,** checked before the plans by index: `spawn singles` 390 → 380 ns, within noise, but `create` 58 → 61.5 ns and `create flat` 64 → 70.5 ns. Worth revisiting if a site's plan lookup shows up in a profile again.
+- **Removing rows last first without grouping moves by pair:** `add tag` 114 ns and `retag` +10%; grouping the arrivals by pair took them to 100 ns and −5%.
+- **Main-thread kernels spawning into the world's batches,** as main-thread systems do, rather than their runner's: `spawn bulk kernel` 17.8–18.6 ns against 17.8–19.3 ns, no gain, and the rows of chunks run on workers would land after every main-thread chunk's, so row order would depend on the worker count.
+- **Blocks of reservations whose unused positions the leak scan finds,** rather than returned by position: `spawn bulk kernel` 15.5 against 10.3 ns, and the scan bumps the generations of indexes never handed out, which wears them toward wrapping. Kept for chunks that fail.
+- **A first block of 64 positions:** 10.3 ns against 10.4 ns starting at 8; 8 is kept, since a kernel spawning a few entities a run returns fewer.
+- **Kernel adds and removes staged as spawns are:** not built. A profile of `add tag kernel` (81.5 ns, below `add tag`'s 96 ns) puts issuing in the kernel at 12% and the sync point at the rest: plan 29%, arrive 19%, sort 12%, writes 7%. Staging would have to bypass the plan, which orders adds against despawns and other commands. Worth revisiting with bulk moves in the plan (design.md).
+
+- **Listing symbol keys with `Reflect.ownKeys`, or with `Object.keys` first:** 1–5% slower than `Object.getOwnPropertySymbols` for 1 to 6 keys (table above), and `Object.keys` finds nothing, since keys are symbols. Worth revisiting if engines give symbol keys an enumeration cache.
+- **U32 ticks:** no measurable gain on the non-sparse 1M benchmarks, 10% on uniformly sparse filters, and change filters go wrong past 2³² ticks unless a clamp pass is added. With ticks kept only where observed, it would help only observed components.
+- **Commands encoded from WASM:** emit 1M 11.2 → 9.2 ms on the main thread and no gain on workers, for about 800 lines across the compiler, code generation, runner, pool, worker and sync point. The sync point is most of emit's time.
+- **Workers spinning 0.15 ms instead of 0.05 ms before waiting:** chain 6×1M on workers 0.83 → 0.525 ms back to back, but only because it bridges the gap between consecutive benchmark runs; per frame it measured the same.
+- **Holding workers spinning while a later tier of the run has kernels,** with no time constant: per frame the same, and move's best case on workers 0.020 → 0.040 ms. Traces showed the 0.05 ms spin already keeps workers awake across tiers (each tier is seen within about 5 µs).
+- **Home ranges sized by each worker's recent share of pieces:** no gain (chain 0.275 → 0.29 ms). Shares never settle: apart from the slowest few workers, each swings by about 40% between rounds, so the sizing chases noise and moves range boundaries, which costs affinity.
+- **Copying numbers and f32 tuples out of command values when issued,** into a typed array the sync point reads, so the issuer's arrays die young: the sync point got 27 ms faster and garbage collection 12 ms, but issuing got 96 ms slower per million spawns (create 1M 294 → ~357 ms). Reading the tuples costs as much at issue time as later, and the extra bookkeeping is more than the sync point saved.
+- **Segments of records, a command at a time, decoded into the world's buffers:** the decode cost 0.9–0.98 ms per run of chromium `emit workers` (100K commands), as much again on a second pass over the same bytes, so instruction-bound, not memory-bound, which put `emit workers` at 8.6–8.8 ms against `efedcd21`'s 8.2–8.4 ms; in node 6.83–6.93 ms against 6.94–7.03. Decoding command by command through `pushCommand` and a per-component push, rather than into arrays fitted once per segment, was slower still: node 7.24–7.49 ms. Columns copied in by the worker, which the world takes views of, took it to 7.76–7.8 ms.
+- **Copying a segment out of the shared ring before decoding it:** chromium drain 0.98 → 1.49 ms; the decode didn't get faster, and the copy cost 0.5 ms.
+- **Inlining the one-word copy of a struct value in `writeRange`, and a views sentinel in place of `null` for buffers without bytes:** no change, sync point 6.1–6.2 ms either way.
+- **Copying drained columns into fresh, exactly sized arrays:** planning 2.60 → 2.45 ms in chromium, but the copies cost more than that.
+- **The main thread claiming pieces too:** no gain; workers that wake late are slow at first, so the main thread does about what it would alone.
+- **A loop per main-thread system** (eval or emitted by the plugin): 5–10% on top of fast-property rows; a micro-benchmark of 50 systems with one loop literal each measured 16%. The tuple each `row[component]` read allocates stays, and it costs more than the shared call site. Worth revisiting with compiled main-thread bodies, where reads become column loads.
+- **A WASM kernel testing block starts in its one row loop,** a block's tick checked at each row that starts one, inside which a chunk's start checks the chunk's: `changed all 100K kernels` 504 → 576 µs, from a branch taken every 64 rows that the predictor misses, where the chunk test it replaced was taken every 1024. Checking blocks only at the eight-row SIMD checks, every eighth of them, still cost 7% in a microbenchmark of one kernel over 100K rows that all changed. The outer loop over runs of blocks takes it to 420 µs.
+- **Every run of passing blocks as its own run in WASM,** however many of a chunk's blocks pass: 1% of 100K rows changed, scattered, one filter, in a microbenchmark, 31 µs against 24 µs for chunks alone, since a run's end costs more than the eight-row checks spend on a block between two runs. Taking a chunk with more than half its blocks passing as one run measured 23.9 µs, more than a quarter 23.9 µs and more than three quarters 32 µs; one changed row 0.21–0.25 µs against 0.33 for chunks alone at each.
+- **Blocks of 32 rows:** against 64, eight systems finding one row of 100K 4.75 against 4.92 µs and ten rows 10.2 against 11.5 µs, but `sparse changed` 421 against 294 µs, a WASM kernel's chunk of 32 blocks with 1% of rows changed having fewer than half passing, so its many runs each pay their end; and twice the memory. Worth revisiting if one-row changes dominate real filters on main-thread systems and WASM finds runs another way.
+- **Several filters scanned filter by filter,** each array's next newer tick found in a loop of its own and the earliest taken, in a microbenchmark of three filters: one change of 10K rows 0.40 against 0.39 µs, 1% of 10K 32.3 against 28.8 µs, 100K rows with nothing changed 0.18 against 0.38 µs. Mixed, so the filters are tested together at each index. Worth revisiting if systems filtering on several components over large archetypes that rarely change show in a profile.
+- **Removing a sync point's rows after all its entries, each archetype's from the highest,** so every row that stays moves at most once: churn 1M +13%, retag +6%. Sorting, the map of rows and a second pass over scattered rows cost more than the copies saved, and copying cells is only about 12% of retag; planning, the system's body and per-entry work make up the rest. Worth revisiting only with column-major moves per pair of archetypes, where removals are batched too.
+- **Unrolled f32 lane writers for staged spawns:** create 1M −5% for 30 more lines. Profiles attribute the caller's tuple allocations to the writer, which inflates it. Worth revisiting if spawns stop allocating tuples.
+- **Faster value-object spawns** (`create flat dynamic`): `Object.keys` and the caller's own spreads dominate, on a path the plugin already avoids for literal keys. Worth revisiting only if spawns from data objects matter to real workloads.
+- **SIMD reductions:** lanes compute in f32 at storage precision, which would round sums into f64 partials. Four rotating scalar lanes took reduce 1M 0.93 → 0.50 ms instead. Worth revisiting with an f64x2 path in the across-rows mode.
+- **Faster WASM lookups** (`follow`): the generated find is already an entity-table check, a directory record and column loads, about 3.8 ns per row of dependent loads. Worth revisiting with a measured breakdown of where those cycles go, such as with lookups batched per archetype.
+- **Positional `commands.add` and `commands.remove` for literal keys,** as the plugin does for spawns: not built. Issuing them, with their key lookups, is about 8% of retag 1M; planning and applying the moves are the rest. Worth revisiting once the sync point's own cost per move is much lower.
+- **Fixed costs per run, measured rather than tried:** a run of a system no entity matches costs about 0.8 µs, fifty of them 0.39 µs each, and a run whose sync point applies one spawn 1.5 µs. Kernels at 1K and 10K rows stay within 2–5× of their best, as at 1M, so small systems hide no large cost.
+- **The world's thread spinning up to 50 µs for a joined thread's next run** before waiting on its posted word: `remote run` 12.4 → 66 µs in node, since the spin holds the world's thread and the run it just started waits behind it.
+- **Runs from joined threads, measured rather than tried:** two node threads waking each other through `Atomics.waitAsync` take 9.7 µs a round trip, so `remote run`, 12.4 µs, spends about 2.7 µs beyond the platform's floor; spinning instead would block the joined thread, which is often the window's. A mailbox adds about 20 µs a tick to `mailbox select 10K`, whose 0.75 ms is the ordered selection the world's thread recomputes, as it would for its own observer.
+- **Checking commands' values for a joined thread's objects as they're issued,** in `commands.add` and prepared add sites, behind a check of whether any thread holds claims: `add value` 95–97 → 100–104 ns in node, measured alternating, with the sync point's own additions about 2% of it. Checked when a system's commands are queued instead, dropping the command and failing its system, where the issuing paths stay as they were; spawns are checked as they're issued, in the object columns' writers, which only objects reach.
+- **The structure epoch turned even by a store, notifying only waiting readers, kept at every sync point:** about 24 ns a sync point against 35 ns, and `sync point one spawn` still a timer step (41 ns) above `c4ecbd8d`; kept only while a joined thread holds claims instead.
+- **Replay finding a pair of archetypes' source columns once per run of its moves:** `log replay` 23.7–24 → 24.7 ns a move, no gain; a mirror's archetypes hold few columns. Worth revisiting with many objects per archetype.
+- **Finding reports to retire through `Report.byRun`,** the sorted index on their run, oldest first: `run failing` 165–196 µs in node acquiring the index for each report and releasing it after, so each rebuilt it, and 87 µs holding it once the first report was spawned, which also keeps the journal recording every later sync point's moves, against 11.7–12.6 µs for the world's own list of the reports it spawned, in run order, with a liveness check per despawn; a failing run without reports, at `3775940d`, is 9.2–9.5 µs, so a report costs about 2.5 µs. Clean runs are unchanged, measured alternating with `3775940d` (`run idle` 333 / 333 ns, `run observer` 166 / 166, `loop tick idle` 1,737 / 1,698, `run 50 idle` 72 / 74 per system, `sync point one spawn` 875 / 833, `remote run` 9.8 / 9.9 µs, medians of six). Worth revisiting only if lookups through a sorted index get far cheaper to set up.
+- **Emptying a run's list of warnings by setting its length to 0** each run: `run idle` 375 → 416 ns in node, measured alternating; the list is counted instead, and the report of warnings alone reused while they're the same.
+- **Moving `placeFinalizer`,** to the end of `finalizers.ts` or into `activate.ts`, its one caller: churn 17.6–18.6 ms either way, since the budget above, not that function, set it.
+- **Writers waiting for a tail to finish instead of snapshotting it,** and **choosing between the two by the tail's rate** (rows read over time since posted, waiting when finishing looked cheaper than copying the rest). Ticks of a world writing every row's place, then working W ms, while the last tick's tail on a joined worker spends T ms on 10,000 rows of a place and a pose, after B ms of other work there; ms a tick, snapshot / waiting / by rate, node then chromium (node's frame is a timer set after each tick):
+
+  | Case | node | chromium |
+  |---|---|---|
+  | frame, typical: T 2.5, W 2 | 20.1 / 20.2 / 20.2 | 16.7 / 16.7 / 16.7 |
+  | frame, B 8 + T 2.5 and W 9: together over a frame | 26.5 / 26.8 / 26.9 | 16.7 / 20.7 (p95 25.5) / 16.7 |
+  | the same, W before the writer | 26.7 / 26.8 / 26.8 | 16.7 / 16.7 / 16.7 |
+  | frame, B 20 + T 2.5, W 3: tail longer than a frame | 23.3 / 26.2 / 22.7 | 22.6 / 26.2 / 22.7 |
+  | fixed 16.7 ms, B 8 + T 2.5, W 9 | 16.7 / 20.2 / 16.7 | 16.7 / 20.2 / 16.7 |
+  | the same, W before the writer | 16.7 / 16.7 / 16.7 | 16.7 / 16.7 / 16.7 |
+  | fixed 4 ms, T 2.5, W 3 | 4.0 / 6.1 / 4.0 | 4.0 / 6.1 / 4.0 |
+  | the same, W before the writer | 4.0 / 4.0 / 4.0 | 4.0 / 4.0 / 4.0 |
+
+  A writer arriving as the tail of 2.6 ms had read 0, about half, 85% and 95% of its rows, chromium, its run in ms: snapshot 0.175 / 0.165 / 0.115 / 0.125, waiting 2.72 / 1.56 / 0.42 / 0.23, by rate 0.2 / 0.205 / 0.155 / 0.13; node alike. The snapshot holds the world's thread 20–72 µs a writer for the copy, waiting 22–27 µs for its spin; the joined thread's time is the same either way, but for one body (Next). By rate never chose to wait in any tick case: a row copies in 6–8 ns, less than any tail's work on it, so finishing is cheaper only within about the last chunk, which the writer waits for anyway. Waiting is worth revisiting if a tick could no longer run ahead of its last tail at all, and by rate if copies grew costly against tails' work per row, as with wide struct reads and light bodies.
+- **Dropping a component's kernel stamps as soon as nothing watches it,** reloading the kernels that write it then, rather than at their next load for another reason: ticks that alternately add and remove a system filtering on `changed` of what a kernel writes, 100 rows, took 216 µs a tick against 13.9 µs, in node, since each removal and each add reloads the kernel, its import and WASM compile on every thread, while a stamp kept costs a store per chunk. Worth revisiting only if stamps of components nothing watches showed up in a kernel's profile.
+- **Checking eight rows' ticks at every row,** rather than at rows aligned to eight: clustered changes 0.023 → 0.108 ms, since each passing row checked a block again. Aligned checks cost clustered changes about 3 µs.
+
+- **Records of every string, kept whether or not a joined thread reads them,** read on the world's thread out of a cache by handle: `string read 10K` 23.1 ns a row against 2.79 for an object, and `string write 10K` 154 ns against 21. Values on the world's thread, and records only while a joined thread may read them, put both at an object's cost.
+- **Encoding through `TextEncoder.encodeInto`,** into shared memory or a scratch buffer copied in, and decoding through `TextDecoder` from a scratch copy: 96–118 ns a 30-character label made and encoded, against 98 for `charCodeAt` into the record; 98 ns a decode against 124 for `String.fromCharCode` over a view, where a joined thread decodes each record once. Both flatten the string first, which most of the time is; `TextDecoder` rejects shared views in browsers.
+- **Copies of strings' records in tail snapshots and observer posts,** let go with the snapshot: not needed, so not kept, since a tick posts its tails once the last tick's are done, a run waits for its tails, and a sync point for every post its thread claimed, so neither outlives the second sync point after the one it read. A tail stalled while runs rewrite what it reads six times sees its tick's strings without them. A post of a system reading only struct resources, which nothing waits for, would need them, so a system reading a string resource doesn't post that way. A joined thread's finalizers, which run whenever the thread replays, read copies in the stop lists.
+
+- **Index builds across the pool as messages,** a message to each worker per phase in five phases: `index rebuild 1M workers` 9.5 ms on nine workers; each phase paid about 0.4 ms of round trips (counting, trivial work, took 0.5 ms). Phases go through the workers' task rings as tasks of a reserved kernel number, their plan in the memory, instead.
+- **A separate scatter phase,** copying listed entries into partition order: 8.35 ms. Counting computes each piece's partition counts and listing writes straight into partition order: 6.7 ms.
+- **A loop over the key's leaves for listing:** 14 ns an entity single-threaded in a microbenchmark, of which the member check costs 2.6 ns, the hash call 2 and the loop over leaves 5. Generated code for the plan's leaves runs about 6 ns; the loop is kept where code can't be generated.
+- **Grouping with each slot's hash beside its bucket in thread scratch:** 7.4 ms single-worker either way; kept, since it reads less.
+- **Building again whenever changed chunks' rows pass an eighth:** `rekey 1M` 46.9 ms, built every frame, since 6% of rows crossing touch every chunk. Counting the rows' own ticks then: 25.9 ms.
+- **Merging a refresh's operations sorted by `Array.prototype.sort` with a comparator:** 25% of `rekey 1M`'s profile. A counting sort by bucket and an insertion sort within each: 14.1 ms.
+- **Schedule depths as an `Int32Array`,** after `loop tick add remove` grew 234–241 → 260–272 ms with indexes (85b434cb, measured alternating against 2898bf26 and at each later commit): `createSchedule`'s 223 eager deopts on the depths array's map went to 3, but the benchmark didn't move, and timing its sections shows a schedule costs the same, about 2.9 µs, before and after. A larger inlining budget, and runners not making `order`'s closures, didn't move it either. Timed in the benchmark, `System.create` takes about 1 µs more a tick and `add` 0.9 µs more, and a micro-benchmark of `System.create` alone collects garbage half again as long; not found yet (Next).
+- **Ordered bodies listing their rows before running them,** as kernels' runs do: `order run 100K` 34.5 ns a row against 31.4 walking the entries.
+
+- **An index without a key as one hash bucket,** zero key words hashing to one bucket in entity order, which every path already read: `keyless refresh 1M 1%` 6.73 ms against 3.43 for a sorted table then, since a long bucket merges its whole length once any entity enters or leaves, and a spawn per frame into 1M would cost an O(1M) merge. `keyless length` was 5.8 ns, against 4.8 for the sorted table's site once it took no arguments.
+- **`copyWithin` for shifts of 3-word entries:** no faster than the loop (`keyless refresh 1M 1%` 3.43 ms either way): a copy within shared memory by 12 bytes moves 4-byte words. Kept only with entries padded to an even number of words (above). Smaller blocks for indexes without a key would halve the shift again, but the 128-entry block is in every reader, WASM included.
+- **Index tables at most a quarter full:** `grid neighbors 100K main` 3.93 → 3.73 µs a row, its misses mostly stopping at the first slot, but `unique lookup 1M` 44 → 53 ns, its slots twice as large and less cached. Half full is kept. Worth revisiting for non-unique indexes only, where slots are small next to entries, if misses dominate a real workload.
+- **An identity or locality-preserving hash for integer keys:** in a microbenchmark of the slot probe over 1M keys, identity takes dense keys in order from 17.8 to 11.4 ns but scattered keys from 18 to 31 ns, and a miss for a key past a dense range scans the whole run of filled slots, 660 µs; keeping a key's high bits and mixing its low ones packs dense keys into slots side by side, 21 µs a lookup. Linear probing needs the hash to spread keys whatever their distribution; a dense direct table beside the hash would be the way to get the 9 ns, at the cost of keeping a second structure and teaching kernels to read it.
+- **Reading a patch's keys, hashes and buckets ahead in batches of 64,** so their misses overlap: `index refresh 1M 1%` 165 → 173 ns and `rekey 1M` 14.7 → 23.7 ms. A move in cache costs the same, so there was little latency to hide.
+- **A list's pool in three banks, its first, last and middle positions,** for hash lists too: `grid neighbors 100K main` 3.63 → 3.84 µs a row from choosing the bank in `at`. Only sorted lists keep a second pool for their last positions.
+- **Making a pool's rows for every position a list holds:** a 100K-row sorted list made 100K rows for a page of 20; rows are made ahead for the first and last 256 positions only.
+- **The tree's build linking parents over locals,** rather than through `link`: the opacity `up` 4.44–4.65 against 4.55–4.76 ms, about 2%, within noise.
+- **An index rebuild listing its entities in one loop over locals,** rather than a closure per entity: `index rebuild 1M main` 28.3–30 against 28.7–34.7 ms, and the editor's layout 2.33–2.84 against 2.35–2.56 ms, no gain.
+- **Binding a row without making a slot object per component:** the editor's paint 5.02–5.06 against 4.99–5.07 ms, no gain; V8 removes the allocation.
+- **Unsorted buckets sorted once their holes and tail passed a quarter of their entries,** rather than when full: `rekey 1M` 15.5 ms against 14.4, sorting buckets of 100 every few frames that nothing reads by position. A bucket at least 256 long before it's left unsorted, shorter ones shifted: 14.8 ms, no better. Merging a long tail an entry at a time rather than by a binary search and a move per tail entry: no measurable difference at `rekey 1M`, 15.4–16.7 ms against 15.4–15.8 then; worth revisiting where tails of thousands are sorted.
+- **Moves of 4-byte words over shared memory,** `copyWithin` on the entries' `Int32Array`: `bucket move 100K in order` 222 µs against 68 with 8-byte words; closing holes by scanning the whole bucket rather than stopping at the last, 245 µs.
+- **Presizing a hash index's table for a rebuild,** measured rather than tried: the editor's 601 parents rehash and place their buckets in 0.2 of 34 ms of profile, since a table is sized for the buckets it last held. Worth revisiting for a first build of an index with as many keys as entities.
+- **Rebuilding an `up` tree from scratch for a large journal range,** rather than patching it: `editor load tick 50K` 20.3 against 20.8 ms, within noise, since building and patching both cost about 30 ns an entity. Worth revisiting if patching gets dearer per entity than a build.
+
+## Next
+
+- `grid neighbors 100K main`, 3.66 µs a row against about 1.6 µs for the kernel on one worker: each neighbor costs about 10 ns in loads of the list's state, the pool and the row's slots; rows whose values carry their index and views as their own fields would save a few of them.
+- Index refreshes, 141 ns a moved entity: two ordered bucket edits and a probe, in cache.
+- `editor load tick 50K`, 18 ms: the shared tree's build and its order's take about 1.5 ms each, 30 ns an entity, spread over linking, settling levels and grouping; the `up` bodies through accessor rows take about 2 ms a system, the 50K ordered paint rows about 2 ms, and each index's rebuild about 1.5 ms, 28 ns an entity listing and encoding its key.
+
+- `loop tick add remove`, a new system each tick: about 2 µs more a tick since indexes (above), in `System.create` and `add`, as more garbage; the paths a run of an existing system takes measure as before.
+- Index rebuilds across the pool: `index rebuild 1M workers` 6.7 ms, nine workers 4.3× one, every phase scattering or gathering by partition; an estimated 2–3 ms if the scatters reached memory bandwidth. Rebuilds are rare, a refresh moving more than an eighth of an index.
+- Single-tier runs on workers: workers asleep at the start of a run take 60–135 µs to see the task, and 2–4 of 9 find nothing left to claim.
+- Idle cores clock down: after 5 ms idle, even the main thread runs move 2–4× slower per frame, and keeping one other core busy removes most of it, at 10M too. That's the OS's power policy, not something dispatch can avoid without spending power.
+- Emit and other command-heavy kernels: the sync point dominates.
+- Replaying the move log: `log replay` takes 24 ns a move in node and 36.5 ns in chromium, two entries each, against about 1 ns to move the bytes; the cost is the per-entry dispatch and the scattered rows a swap reads.
+- Ordered selections recomputed every tick: `joined observer 10K` spends most of its 0.4–0.5 ms a tick sorting 10K entities.
+- `joined observer 10K`, back to back: lookups read the rows in place, so the world's writer waits for each run the thread claimed, about 1.07 ms, in 1,451 of 3,000 ticks; the thread's run is mostly the benchmark's own sort, and of the rest `at` through the index without a key.
+- A tail's body reading from a snapshot ran slower in one case: a loop counted down from an unbounded integer resource (an f64) took 13.6 ms against 11.2 in place over 10,000 rows of 200 steps, in node, while counted as an i32 it took 10.8 against 11.2; deopts didn't account for it.
+- Main-thread spawns reserving in blocks too: `spawn bulk` still takes one atomic add per spawn. Finalizers spawn during the sync point, after it materializes the run's reservations, so a world's block would have to end before each materialization.