There is no reason I can think of why a Wasm interpreter would have higher overhead for arguments in and out. Maybe I'm missing something? Wasm was designed to

There is no reason I can think of why a Wasm interpreter would have higher overhead for arguments in and out. Maybe I'm missing something? Wasm was designed to have very fast calls, both internally and externally. That's why the basic types correspond directly to machine types. The goal is to have 0 overhead, except for sandboxing. Regarding sandboxing, there is the stack overflow check that happens in Wasm on each call. But you can disable that check if you don't want it. Btw, you can see that Wasm has no extra overhead on calls in a simple way: compile Wasm using wasm2c and inspect the C output. That C is what a Wasm VM would run. Some details: https://kripken.github.io/blog/wasm/2020/07/27/wasmboxc.html https://kripken.github.io/blog/wasm/2020/07/27/wasmboxc.html Note the section there about LTO: The Wasm can even be inlined into the code calling into it, which means there is zero call overhead. (But even without LTO, it's just another C function to call.)