(no title)
ruds
|
1 year ago
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).
cogman10|1 year ago
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.
michaelothomas|1 year ago
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.