WebAssembly Runtimes Are Getting Faster, and One New Instruction Closes the Gap to Native
Performance of WebAssembly Runtimes in 2026
A follow-up to libsodium WebAssembly benchmarks from 2019, 2021, and 2023 tests whether runtimes released in 2024, 2025, and 2026 are actually improving. Wasmer leads overall, but WAVM, WAMR, and Wasmtime are close. The new wide_arithmetic instructions deliver the biggest gains: Wasmtime drops from 2.41x native to 1.46x, and Wasmer from 2.08x to 1.33x. Wasmtime and Bun improve steadily; Wazero stays flat.
But when wide_arithmetic worked, it was the biggest speedup in the whole experiment: Wasmtime 46.0.0: 2.41x native without it, 1.46x native with it. Wasmer 7.1.0: 2.08x native without it, 1.33x native with it.
- azakai
Judging by the slow speed of node here, I wonder if it was run without forcing optimizations. It doesn't do OSR (on-stack replacement), meaning that a benchmark script doesn't get a chance to tier up from the baseline compiler to the fully optimized tier.
Running with
node --no-liftoff
avoids this problem.
(This is not an issue on the Web, where code must return to the event loop anyhow, allowing tiering up to work, and node is optimized for that kind of workflow.)
- pmkary
Many moons ago I was preparing for an interview to join wasmer, back then they showed me that by running wasmer as a kernel extension in Linux they have made it run four orders of magnitude (10,000 times) faster. Given the WASI, I keep thinking more than the plugin usability of things like wasmer, what is the point of WASM not being accepted as a second binary in all operating systems? Windows could support .exe as well as .wasm for example and we would finally have a cross-plaform binary. Apple would never accept; Microsoft will do, and Linux can simply have,
- ncruces
Curious where my wasm2go would stand compared to wazero. I should test it myself. :)