4 ms·

He makes a point of showing how hard it is to achieve the same performance as JS with wasm, but the majority of the problems he runs into are AssemblyScript-rel

He makes a point of showing how hard it is to achieve the same performance as JS with wasm, but the majority of the problems he runs into are AssemblyScript-related. Also he doesn't mention that wasm is faster to parse than JS. I'd be interested in a comparison of JS and wasm from the POV of a UI-heavy, compute-light app.

pornel 4y ago
While just the parsing step may be faster indeed, I don't think that aspect alone is enough to make a difference for an application. Browsers are often able to defer parsing of JS functions until they're called, so dead JS code doesn't cost much in parsing time. In JS first run goes through an interpreter (without a delay for compilation/optimization), so JS has a pretty low latency for initial execution. JS is relatively easy to split into pieces and lazy load (there are various bundlers that support "chunking"), and not loading code is faster than fastest parsers. WASM could theoretically do that too, but current languages and tooling are more geared towards monolithic executables. For UI, where time to interactive matters most, JS will likely do a better than a big blob of WASM. WASM still needs to call out to JS for DOM interactions, so if your UI is DOM-based, you'll need a bunch of JS anyway, and have JS<>WASM communication overhead.
- jagged-chisel 4y ago
  Does wasm support anything other than monolithic executables? The last I used it, multiple wasm bundles had to be loaded up by JavaScript and glued together with JavaScript.
- saagarjha 4y ago
  > Browsers are often able to defer parsing of JS functions until they're called, so dead JS code doesn't cost much in parsing time. You sure? Just figuring out what to call us going to typically require full parsing to find identifiers, scoping, etc.
  - Leszek 4y ago
    Browsers do a fast partial parse to figure out things like scoping and variable names, but skip actually building an AST so it's still a lot quicker than full parsing (e.g. https://v8.dev/blog/preparser https://v8.dev/blog/preparser)
game-of-throws 4y ago
js-framework-benchmark is the standard benchmark for UI-heavy, compute-light JS. https://krausest.github.io/js-framework-benchmark/current.html https://krausest.github.io/js-framework-benchmark/current.ht... To see results, show "vanillajs-1" and "wasm-bindgen", then hide everything else. WASM is about 6% slower, 18% longer startup, and 66% more memory usage. Note this is a UI benchmark so the results are overwhelmingly dominated by DOM interop. Things should improve if the WASM interface types proposal ever lands.
- RobbieGM 4y ago
  I get that it would have a startup cost but I'm shocked that it uses more memory. Everyone complains about what a memory hog electron apps are and I assumed it was because of JS. But maybe we need something other than micro benchmarks to compare.
  - game-of-throws 4y ago
    The absolute numbers aren't that different. You need 100s of MB just to display an empty Chrome window. Then the 66% is the difference excluding that baseline, e.g. it might be 300MB to load Chrome, then you measure 301MB vs 301.66MB. I guess that might be a bit misleading. I think the electron memory usage comes down to the massive HTML spec and bloated old browser codebases. It's not JS. Node+V8 doesn't have nearly the memory usage of Chrome+V8.
    - RobbieGM 4y ago
      That difference is what I'd be interested in anyway as a developer who focuses on PWAs (where the cost of chrome is paid for already). I'm trying to work out whether a WASM stack would help runtime performance, memory usage, and startup time, but based on these numbers it doesn't look so inspiring.

pornel 4y ago

While just the parsing step may be faster indeed, I don't think that aspect alone is enough to make a difference for an application. Browsers are often able to defer parsing of JS functions until they're called, so dead JS code doesn't cost much in parsing time. In JS first run goes through an interpreter (without a delay for compilation/optimization), so JS has a pretty low latency for initial execution. JS is relatively easy to split into pieces and lazy load (there are various bundlers that support "chunking"), and not loading code is faster than fastest parsers. WASM could theoretically do that too, but current languages and tooling are more geared towards monolithic executables. For UI, where time to interactive matters most, JS will likely do a better than a big blob of WASM. WASM still needs to call out to JS for DOM interactions, so if your UI is DOM-based, you'll need a bunch of JS anyway, and have JS<>WASM communication overhead.

jagged-chisel 4y ago
Does wasm support anything other than monolithic executables? The last I used it, multiple wasm bundles had to be loaded up by JavaScript and glued together with JavaScript.
saagarjha 4y ago
> Browsers are often able to defer parsing of JS functions until they're called, so dead JS code doesn't cost much in parsing time. You sure? Just figuring out what to call us going to typically require full parsing to find identifiers, scoping, etc.
- Leszek 4y ago
  Browsers do a fast partial parse to figure out things like scoping and variable names, but skip actually building an AST so it's still a lot quicker than full parsing (e.g. https://v8.dev/blog/preparser https://v8.dev/blog/preparser)

game-of-throws 4y ago

js-framework-benchmark is the standard benchmark for UI-heavy, compute-light JS. https://krausest.github.io/js-framework-benchmark/current.html https://krausest.github.io/js-framework-benchmark/current.ht... To see results, show "vanillajs-1" and "wasm-bindgen", then hide everything else. WASM is about 6% slower, 18% longer startup, and 66% more memory usage. Note this is a UI benchmark so the results are overwhelmingly dominated by DOM interop. Things should improve if the WASM interface types proposal ever lands.

RobbieGM 4y ago
I get that it would have a startup cost but I'm shocked that it uses more memory. Everyone complains about what a memory hog electron apps are and I assumed it was because of JS. But maybe we need something other than micro benchmarks to compare.
- game-of-throws 4y ago
  The absolute numbers aren't that different. You need 100s of MB just to display an empty Chrome window. Then the 66% is the difference excluding that baseline, e.g. it might be 300MB to load Chrome, then you measure 301MB vs 301.66MB. I guess that might be a bit misleading. I think the electron memory usage comes down to the massive HTML spec and bloated old browser codebases. It's not JS. Node+V8 doesn't have nearly the memory usage of Chrome+V8.
  - RobbieGM 4y ago
    That difference is what I'd be interested in anyway as a developer who focuses on PWAs (where the cost of chrome is paid for already). I'm trying to work out whether a WASM stack would help runtime performance, memory usage, and startup time, but based on these numbers it doesn't look so inspiring.