Recorded benchmarks

README · Documentation

Historical collection measurements, including slower workloads, memory costs, and reproduction commands. These are not measurements of task dispatch or worker-pool overhead.

Performance#

Zerocopy vs Immutable.js vs native collections. Shared means zerocopy. Times cover complete workloads, not single calls. Lower times are better. Ratios compare Shared with the named reference.

Measured on September 14, 2026, in the GitHub validation run. The runner used Bun 1.4.2, Immutable.js 5.1.9, AssemblyScript 0.28.20, Linux x64, and an AMD EPYC 7763 processor. Each result is the median of 45 samples across three process rounds, with ten warm-ups per case and rotated library order. Results and retained bases are checked outside timing.

The first tables exclude arena creation and use repeated reads. Every build creates a fresh collection through individual persistent updates. First-use results below include arena creation. Native builds use a fresh mutable Map or Array. Updates to an existing native collection include one copy per workload to preserve its base, then apply changes to that copy. Shared and Immutable.js return new versions at each scalar update.

Build, read, peek, and scan rows process 10,000 items unless stated otherwise. Removal rows apply ten removals to a 10,000-item base. setMany(100) changes 100 entries; Immutable.js uses persistent set, not withMutations. enq+deq(100) performs 100 enqueue/dequeue pairs. Linked-list indexed reads cover 100 positions; front/back reads cover 50 each. Map and ordered-map values are strings. Sequence and sorted-map values are numbers. Sorted keys use a fixed shuffled insertion order; native sorted iteration includes sorting.

Benchmark Results (N=10000)#

SharedMap vs Immutable.Map vs Native Map

SharedList vs Immutable.List vs Native Array

SharedStack vs Immutable.Stack vs Native Array

SharedQueue vs Native Array

SharedLinkedList vs Native Array

SharedDoublyLinkedList vs Native Array

SharedOrderedMap vs Immutable.OrderedMap vs Native Map

SharedSortedMap vs Native Map

The string SharedMap.set workload is 1.46x faster than Immutable.js in this run. Results near 1.00x are not established improvements. These are Bun microbenchmarks, not application, browser, or worker-transfer speed guarantees.

First-use builds, including arena creation#

This table includes Shared arena reset, new WebAssembly memory, and WASM instance creation inside the timed workload. Inputs and sample counts are the same as above. Immutable.js and native collections have no equivalent arena initialization cost.

Scalar map writes across different keys#

These tests call ordinary set for every update. They do not use a bulk builder, withMutations, or repeated changes to a few keys. The insert order is a fixed shuffle. Overwrite rows change 1,000 distinct keys in a 10,000-item base. The long-prefix case uses a shared 128-character key prefix. The fork row creates 64 separate snapshots from one base; native copies once per fork. All returned versions are immediately readable and shareable.

Each workload and library runs in an independent process for each round. There are 45 timed samples per cell. Setup and full output checks are outside timing, except arena creation in the explicitly marked first-use row.

Numeric insertion and dispersed numeric overwrites exceed 2x Immutable.js in this run. String insertion reaches 1.99x. Unicode construction and independent forks are slower than Immutable.js. There is no general 2x scalar-write advantage.

Cold reads, larger key sets, and mixed updates#

A repeated read can use a bounded process-local cache. The first-read case attaches an empty read cache before each timed scan. The 32,768-key case exceeds the value-cache entry limit. The mixed case changes a key, reads its new value, and checks membership 1,024 times. The final case alternates reads between two retained snapshots. Each cell has 45 samples.

These fixed-order workloads differ from the independent-process shuffled write suite. Warm lookup gains are not uncached lookup gains; the mixed-update rows measure different access patterns.

Evidence#

The recorded summary contains scalar-write medians, memory results, source and driver checksums, and test counts. The raw archive contains 1,800 paired scalar-write timing samples, 4,005 original-table samples, 1,080 first-use samples, 540 extra read-workload samples, 108 isolated memory measurements, and test logs. Artifact retention ends on December 13, 2026.

The scalar-write report explains the comparison with the same engine without the writer index. Earlier experiments retain their own source versions, raw data, and results; they are not measurements of the current source.

Memory: Shared vs Immutable.js vs native#

Lower memory is better. One MiB is 1,048,576 bytes. These measurements use the same validated source and runner as the speed tables. They compare libraries, not different zerocopy releases.

The metric is incremental post-GC V8 heap use plus full retained backing buffers. It includes Shared's JavaScript keys, values, caches, wrappers, auxiliary buffers, and unused space in active WASM memory. It is not a comparison of Shared payload bytes with another library's complete storage.

Node.js v22.23.2 runs each library, type, size, and scenario in an isolated process with --expose-gc. Results are medians of three independent processes. Library imports, warm-up, and empty default arenas precede the heap baseline. Startup, code memory, total process RSS, and peak temporary memory are excluded.

One retained collection after reads#

Maps use string keys and string values. Lists and stacks use numbers. Construction uses scalar writes. All values are checked before measurement, so Shared's read-cache cost is included. Only the latest handle is retained, but Shared arenas still contain allocated intermediate nodes.

The 10,000-item map uses 4.1% less than Immutable.js in this run, while the 100,000-item map uses 22.7% less. Treat the small difference at 10,000 items with care because heap measurements vary. Shared still uses more memory than native Map. The writer index adds no reserved backing memory: its scratch area fits in the prefix already reserved by each arena.

Compacted collections and retained history#

Compacted rows rebuild Shared's live data in a fresh arena. The source and its default arena reference are released, then all live values are checked again. The other libraries use their normal GC-managed representations. Compaction time and peak memory while both arenas coexist are not included in retained size.

History rows keep 32 snapshots of a 10,000-key map while changing one key. Shared and Immutable.js retain versions; native Map retains 31 shallow copies plus its original. Only the changed key is checked in these history cases. Their cache state differs from the full-read cases above.

Compaction is explicit, not automatic reclamation. Old snapshots, workers, payloads, nested values, or default references can keep the source arena alive. An arena reserves at least 128 KiB. The tables do not imply that every Shared collection is smaller than every alternative. Only directly corresponding Map, OrderedMap, List/Array, and Stack/Array representations are measured here. Missing Immutable.js types are not substituted with unrelated types.

Reproduce the timing and memory comparisons#

From the project directory:

bun install
bun run build:wasm
bun run build:browser
bash proofs/run-hot-path-evidence.sh

This records the eight timing tables for initialized arenas, first-use builds with arena creation, cold and mixed reads, and the three-library memory comparison. All variants retain the same inputs and validate their results. Raw JSON and generated tables are written below proofs/results/hot-path/ and proofs/results/cold-build/.

Run the independent-process scalar-write comparison:

node proofs/run-map-set.mjs proofs/results/map-set.json

Run only the memory comparison after the portable build:

node proofs/library-memory.mjs proofs/results/library-memory.json

The driver starts isolated child processes with explicit garbage collection. It saves samples, heap measurements, backing-buffer totals, library versions, and checksums. Later runtimes or different hardware can produce different results. Keep new runs separate from the recorded summary.