The repo's own control run deleted the 5-10x WASM claim from vizcrush's launch copy

The null result has a mundane mechanism, and the author names it. LTTB's inner loop is an argmax: it compares an area against a running maximum on every candidate point, and the stats kernel skips non-finite values while tracking min and max, also per element ^[13]. Neither loop autovectorized in these builds, and there are no hand-written SIMD intrinsics in the Rust to force the issue ^[14]. The flag granted a permission the code could not use. That is also why the doc comment in `stats.rs` describing a "SIMD pre-scan" was removed rather than reworded: it described code that does not exist ^[15].

Note the instrument order. Identical bytes cannot run at different speeds, so hashing two builds answers "is this flag doing anything" more cleanly than a stopwatch does, and it answers it before anyone argues about variance. The timings came second and agreed at every size ^[10].

Then the copy. The surviving comparison is 1.72ms against 55.52ms ^[3], which divides out to 32.3x ^[1] and backs the advertised 32x ^[1]. Compound that with the claimed extra 5-10x from WASM and the launch page was promising 160x to 320x over the npm package ^[2].

The parity figure transfers only under conditions the harness states. You would have to be calling raw WASM exports directly, since marshalling was deliberately kept out of the comparison, on an engine like Node v24.14.1 on darwin/arm64, with absolutes read as approximate and only the ratios trusted ^[11]. You would also have to be running one of these kernels. The author is explicit that which backend wins is algorithm- and engine-dependent, and that the finding covers these specific kernels rather than settling WASM versus JS for the library as a whole ^[19].

The subplot belongs in a postmortem template. The shipped binaries had never been through `wasm-opt`, because the build script invoked it only when binaryen happened to be installed, and it wasn't, for the project's entire life ^[16]. A step gated on a missing tool never runs at all. Fixing it so that it now fails loudly bought a 10-12% smaller binary and no speed: LTTB measured 1.05-1.10x, marginally slower, and stats 1.00x ^[17]. The fix itself was minor; disclosing plainly that it changed nothing at runtime is the more useful piece of craft here.

ADR 0002 keeps `+simd128` anyway, on the grounds that it is harmless and occasionally shrinks a binary ^[18]. That is the correct disposition for a flag whose cost is zero and whose benefit is unproven. Softening the claim was equally available: "up to 5-10x on some workloads" would have survived contact with this control run and stayed unfalsifiable indefinitely. Deleting it instead leaves the repo's claim set mapping one-to-one onto its result files, which is the only property that makes a vendor's benchmark table worth opening. For a library whose backend is explicitly selectable ^[6], I think that is the right trade, because the person choosing a backend is the person who needs the number, and dispatch is still availability-based pending further investigation ^[20].