I'm surprised it was twice as slow. Just this past week I was playing around with WASM, running some pure math calculations and comparing them against a JS version. I was seeing a 10x perf increase, though I was writing WAT directly, not compiling C or anything like that.
"For example, they had a core data structure in Sheets which was blurring the lines between arrays and maps. This is efficient in JavaScript, which automatically models sparse arrays as maps, but slow on other platforms. ""
"Of the optimizations they found, a few categories emerged:
Replicating core optimizations that already existed in the Java Virtual Machine (JVM) and in V8.
Using highly optimized browser APIs.
Removing JavaScript-specific coding patterns"
Basically it seems, they tried to copy their js code. And this unsurprisingly did not work out well. They had to reimplement some critical parts.
Note -- AIUI the js and wasmgc are both produced from the same Java codebase. The problem here is that the developers on the Java codebase had started making changes based on their performance when transpiled to javascript (which is only natural -- it seems that they had been targeting js output for a decade).
For example, they point out that they got 40% improvement by adding devirtualization to the compiler. Java by its nature likes to add a whole bunch of virtual method calls. Java devs primarily rely on the JIT to fix that up (and it works pretty well). Javascript relies similarly on that sort of optimization.
WASM, on the other hand, was built first to compile C/C++/Rust code which frequently avoids (or compiles away when it can) virtual method calls.
I imagine this isn't the only issue. For example, I'll guess that dealing with boxing/unboxing of things also introduces a headache that wouldn't be present in similar C/C++ code.
In short, it just so happens that a lot of the optimizations which benefit JS also benefit Java. The one example where they did a Javascript optimization was prefering Maps and Lists over PoJos.
We had a pretty awesome team of people working across the entire stack optimizing absolutely everything. The blog post only talks about the three optimizations that made the biggest difference.
Likely because they are compiling Java with WasmGC extensions and stuff. If you try C, Rust, Zig etc they tend to run extremely fast in WASM.
Go also has a WASM target which runs pretty slow compared to its native binaries. GC extensions might help but as far as I can remember, Go's memory model does not fit the WasmGC so it might never be implemented.
I'm somewhat curious why they even chose Java over Rust or Zig, considering the spreadsheet data paths should be relatively straight forward even with a lot of clone() activity.
