3 ms·
My general worry is that the performance gains from using some WASM will just get eaten up by the overhead of jump between JS and WASM and having to copy/conver
by sime2009 6y ago
My general worry is that the performance gains from using some WASM will just get eaten up by the overhead of jump between JS and WASM and having to copy/convert data. You might be able reduce the problem by porting more stuff from the JS side to the WASM side, but then you risks pulling in huge chunks of your app.
- alpaca128 6y agoAny real performance gains will easily be balanced out by websites doubling their size once again, WASM or not.
- elenchev 6y agoJS <--> WASM function calls are not an issue[1], passing large amounts of data is though. 1. https://hacks.mozilla.org/2018/10/calls-between-javascript-and-webassembly-are-finally-fast-%F0%9F%8E%89/ https://hacks.mozilla.org/2018/10/calls-between-javascript-a...
- sime2009 6y agoDoes anyone know if that is also the case on V8?
- flohofwoe 6y agoJS/WASM calls are fast in V8, and still seem to be improved from time to time (e.g. see: https://v8.dev/blog/v8-release-90#webassembly https://v8.dev/blog/v8-release-90#webassembly), not sure about any large data optimizations (TBH I'm not sure what this is about though, because usually one would use JS slices into the WASM heap to avoid redundant copying)
- cdcarter 6y agoThat works if the data is already in the Wasm linear memory and you need to access it from JS. If you have strings (or whatever) in JS, you need to copy them into the linear memory for the Wasm module to use.