35 ms·

Is there an performance gain in using WASM?

by neals 9y ago

steveklabnik 9y ago
In general, there should be, but it depends on what you're doing. For example, wasm can't access the DOM directly yet, so you have to call back into JS to do it, which is much slower than the eventual native API will be. For stuff like this, though, it should have much lower overhead.
- k__ 9y ago
  Wasn't the main point of WASM that it is faster to parse than JavaScript?
  - steveklabnik 9y ago
    It's one of the main points, yes. Parsing isn't the only aspect of overall performance, though.
    - deleted 9y ago
      [deleted]
  - flohofwoe 9y ago
    Parsing of WASM byte code is massively faster* than parsing JS source code, but calling back and forth between JS and WASM is an entirely different topic. It's not that slow though, for instance each call to WebGL incurs that overhead, but the overhead is small enough that it doesn't matter that much (for overall performance) compared to asm.js or "normal" JS code. Still, if you want the best performance, avoid as many calls into the JS side as possible (e.g. by eliminating redundant WebGL calls). edit: * at least in Firefox, Chrome still has some... potential :)
  - j1vms 9y ago
    > Wasn't the main point of WASM that it is faster to parse than JavaScript? That is only one of the advantages of WASM. The major advantage is that seen by CPU-bound code sections where WASM can be efficiently executed at "near" native speed. Conversely, this performance advantage is not enjoyed by I/O-heavy operations which will not see any major improvement versus regular JS - this is roughly due to the browser having to apply sandboxing/security/protection (or by just forcing you to make JS calls to achieve this).
Schampu 9y ago
It's possible to come up with a close result with JS, but with WASM you have a lot space to add more things on top than just moving a particle back to it's origin.
flohofwoe 9y ago
The last point in my handy WASM FAQ explains the main reasons why WASM (and also asm.js) is faster than 'idiomatic' Javascript: http://floooh.github.io/2017/06/09/webassembly-demystified.html http://floooh.github.io/2017/06/09/webassembly-demystified.h...

Is there an performance gain in using WASM?

by neals 9y ago

Is there an performance gain in using WASM?

In general, there should be, but it depends on what you're doing. For example, wasm can't access the DOM directly yet, so you have to call back into JS to do it, which is much slower than the eventual native API will be. For stuff like this, though, it should have much lower overhead.

k__ 9y ago
Wasn't the main point of WASM that it is faster to parse than JavaScript?
- steveklabnik 9y ago
  It's one of the main points, yes. Parsing isn't the only aspect of overall performance, though.
  - deleted 9y ago
    [deleted]
- flohofwoe 9y ago
  Parsing of WASM byte code is massively faster* than parsing JS source code, but calling back and forth between JS and WASM is an entirely different topic. It's not that slow though, for instance each call to WebGL incurs that overhead, but the overhead is small enough that it doesn't matter that much (for overall performance) compared to asm.js or "normal" JS code. Still, if you want the best performance, avoid as many calls into the JS side as possible (e.g. by eliminating redundant WebGL calls). edit: * at least in Firefox, Chrome still has some... potential :)
- j1vms 9y ago
  > Wasn't the main point of WASM that it is faster to parse than JavaScript? That is only one of the advantages of WASM. The major advantage is that seen by CPU-bound code sections where WASM can be efficiently executed at "near" native speed. Conversely, this performance advantage is not enjoyed by I/O-heavy operations which will not see any major improvement versus regular JS - this is roughly due to the browser having to apply sandboxing/security/protection (or by just forcing you to make JS calls to achieve this).

Schampu 9y ago

It's possible to come up with a close result with JS, but with WASM you have a lot space to add more things on top than just moving a particle back to it's origin.

flohofwoe 9y ago

The last point in my handy WASM FAQ explains the main reasons why WASM (and also asm.js) is faster than 'idiomatic' Javascript: http://floooh.github.io/2017/06/09/webassembly-demystified.html http://floooh.github.io/2017/06/09/webassembly-demystified.h...