Wasmi 2.0 ships direct-threaded Wasm dispatch mode, ~2.2x faster than 1.0

The shape of the change is a rewrite of the dispatch model. Wasmi 1.0 ran instructions through a switch-loop, and Wasmi 2.0 now exposes direct-threaded code as the fastest path. The article characterizes direct-threaded code as embedding function pointers into the internal IR and chaining instruction handlers via tail calls; indirect-threaded code is the same idea with op-codes plus a jump table, sitting roughly 10 to 15% slower but using significantly less IR memory. Switch-loop is retained for platforms that do not support tail calls, and call-loop is described as existing only because portable-dispatch and indirect-dispatch are independent crate features, with the author explicitly saying it cannot be recommended.

The cost of adoption is choosing a dispatch mode through crate features (indirect-dispatch, portable-dispatch, auto-dispatch) and accepting that the fastest path is only available where the target toolchain supports tail calls. The article frames direct-threaded code as the same architecture used by both Wasm3 and Makepad Stitch, which places Wasmi 2.0 in the same family on those platforms rather than as a wholly new design. The maintainer also flags that switch-loop "leaves a lot of performance on the table, especially on Apple Silicon," so picking the portable default has a real per-platform cost rather than being a free fallback.

Where it stops working is anything that cannot rely on tail calls, which falls back to switch-loop and is described as the slowest supported path. Call-loop is explicitly called out as "very slow and not memory efficient." The article does not enumerate which targets or toolchains fail tail-call support, so an adopter still has to verify on the architecture they ship to. Startup performance is described as "mostly on par" with Wasmi 1.0 rather than improved, meaning the headline gain is in steady-state execution, not module loading.

The evidence base is narrow. The 2.2x figure is geometric mean across the wasmi-benchmarks suite on Apple M2 Pro, and the cross-runtime comparison was rerun on AMD EPYC 7763 and Intel Xeon Platinum 8370C. Only one feed in the inputs carries this release, so there is no independent benchmark corroboration in the provided material. The article also notes that the comparison plot needed logarithmic scaling on the startup axis because Wasmtime Pulley is an outlier, which is worth knowing before reading the startup chart as if it were linear.

Adjacent changes ride along with the engine rewrite. Stable fuel metering, the WebAssembly deterministic profile and an improved CLI were added on user request, and a validate crate feature is positioned as a knob for reducing binary artifact size, relevant to the IoT and embedded-console use cases the article names. The maintainer thanks Felix Kutzner for proofreading and credits the Stellar Development Foundation with sponsoring the project since October 2024, while listing Typst, Zellij, Josh, Soroban, Ripple and Firefly Zero as the kind of embedded consumers where the dispatch-mode trade-off actually shows up in production.