When you said I was wrong I knew right away you either never actually tested or you're talking about outside of the browser. If it wasn't clear I was talking about wasm in chrome/safari/firefox this entire time
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.)
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?
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).