Why memory64 can be slower

• Bounds checks: On 64-bit hosts, engines reserve 4 GiB of address space for a wasm32 memory, so most bounds checks can be left out. A 64-bit index can't be handled that way, so every load and store pays for an explicit check. The SpiderMonkey team measured slowdowns ranging from 10% to over 100%, depending on the workload.
• Bigger pointers: usize and pointers grow from 4 to 8 bytes. Pointer-heavy data such as Vec headers, hash map entries, and ECS archetype and table metadata gets bigger, so it uses more memory and cache. The peak memory column shows this.
• What you get in return: wasm32 can address at most 4 GiB. The WebAssembly JS API caps memory64 at 16 GiB.

Methodology

• Both modules come from the same crate, built with the same pinned nightly Rust compiler, flags, and wasm-opt pass. Both builds compile std from source with -Zbuild-std, because wasm64-unknown-unknown is a tier 3 target with no prebuilt std. The target is the only difference.
• Inputs come from a fixed seed, so both builds do the same work. The Output column checks that the checksums from every sample are identical.
• Each workload starts in a fresh worker. Both builds load and prepare their inputs untimed before either runs. A shared repetition count is then calibrated so each timed sample lasts tens of milliseconds, and the builds alternate untimed warm-up rounds (at least half a second in total) so the JIT can tier up. Timed samples also alternate which build goes first.
• Memory64 shipped in Chrome 133 and Firefox 134. Results differ between engines, so test the browsers you're targeting.