Which backend wins is engine- and workload-dependent, and vizcrush publishes the cases where
WASM loses as well as the ones where it wins. Rather than ask you to take that on faith,
this runs the real LTTB kernel on both backends, on your machine, through the same public
API your code would call — and shows you what it measures, including when the answer is
“no meaningful difference”.
loading…
How this measures
Nothing renders while timing. A benchmark taken with a canvas animation running measured
an identical typed-array loop 4.7x slower than the same loop in an idle tab, so the
chart is drawn once and then left alone.
3 warm-up calls, then 7 timed repetitions. Median, min and max are all shown, because a
single run is noise and a spread you cannot see is a spread you will misread.
Both backends run the same seeded input, and their outputs are compared before their
speeds are: a faster wrong answer is not a faster answer.
Ratios below roughly 1.15x are reported as a tie. At seven samples, they are.
What this cannot tell you
One machine, one engine, one workload. LTTB's inner loop is an argmax with a branch on
every point, which is why SIMD does nothing for it (ADR 0002) and why these numbers should not be generalised to other kernels (ADR 0003).
Expect roughly parity here, not the 4x from ADR 0003. That figure comes
from calling the raw wasm-bindgen export directly, in headless Chromium, where the JS
core runs about 3x slower than it does in Node. This page calls the public API instead,
which marshals your arrays across the JS↔WASM boundary the way real callers do.
Measured end-to-end that way,
ADR 0001
already records wasm/js ≈ 1.00x for LTTB at 1M and 10M points. If
this page shows you a tie, it is agreeing with the repo, not contradicting it.
Cold start is excluded by the warm-up. First-call cost is real, and on every engine
measured it is worse for WASM than for JS.