> When you said I was wrong I knew right away you either never actually tested or you're talking about outside of the browser.

No, I actually was talking about the browser.

And I have actually tested. You'll find my name on a bunch of public benchmark results about wasm and its predecessor asm.js, all in a Web context,

* Various benchmark posts on Mozilla Hacks: https://hacks.mozilla.org/author/azakaimozilla-com/

* The original wasm paper: https://people.mpi-sws.org/~rossberg/papers/Haas,%20Rossberg...

* The WasmBoxC post: https://kripken.github.io/blog/wasm/2020/07/27/wasmboxc.html

And specifically SQLite is a benchmark that I've looked at many times over the years. It's an important codebase. That's why I added it to the Emscripten benchmark suite, and why it is measured in that last link.

(Fyi, I am one of the co-creators of WebAssembly, I created Emscripten, and I have been working in the compile-stuff-to-the-Web space for over a decade.)

There's two things I always wanted to know

1. Why wasn't realloc part of the spec? When I looked at wasm and emscripten it appeared that realloc was essentially malloc+memcpy? That'd be painful when arrays are bigger than L2 or L3 cache. I think I heard arm cpu's all standardized to have virtual memory in 2005 or 2010 so I don't think arm hardware was an issue?

2. It seems like 100% of system calls would have to be implemented through javascript? Why wasn't there some things wasm implemented itself like a way to get time or rdtsc, realloc and other very common operations?

In both cases the idea was to start simple in wasm 1.0 and leave those things for later. Both are being discussed now.

For the first see e.g. https://github.com/WebAssembly/design/issues/1397

For the second, WASI is doing that on the server, while on the Web we just haven't found a way that is better/faster than calling through JavaScript (we tried to do direct WebIDL bindings among other things).