4 ms·
Compiling JavaScript into WASM is most likely not going to result in better performance unless you make an extremely good static optimizing compiler, and probab
by gliptic 11y ago
Compiling JavaScript into WASM is most likely not going to result in better performance unless you make an extremely good static optimizing compiler, and probably not even then. It's very hard to do the kind of optimizations that JIT compilers do ahead of time, in one single static binary.
- xigency 11y agoPull the developers (or poll them) from V8 and ask them what they think. All of the "just-in-time" optimizations can be done ahead of time. Which saves [that much run time x that many users] in computer time.
- gliptic 11y agoI don't know why you refer to V8. V8 isn't doing AOT compilation of general JavaScript.
- jfbastien 11y agoEveryone on V8 would disagree with you :-) Type tracing in particular is the big win, and with a dynamic languages you simply can't prove enough to do it ahead of time. There's also startup time that you're paying with AOT and avoiding with JIT.
- mason55 11y ago> Type tracing in particular is the big win, and with a dynamic languages you simply can't prove enough to do it ahead of time. The post I originally replied to brought this up in the context of TypeScript with the aside that TypeScript is basically JavaScript. Do you think that using TypeScript's static typing and compiling to wasm could/would be faster than JIT-compiled JavaScript?
- AgentME 11y agoAgreed. The entire point of asm.js (which WASM is currently just a compact encoding of) is that it's a simpler subset of javascript that's easier to optimize. If you could transform arbitrary Javascript into asm.js efficiently, then similarly you could also apply asm.js's optimizations to arbitrary Javascript, and the whole asm.js part would be pointless.