5 ms·
> From what I understand, calling WebAssembly functions from JavaScript (and vice-versa) incur a runtime penalty that's way worse than calling JavaScript functi
by trgv 9y ago
> From what I understand, calling WebAssembly functions from JavaScript (and vice-versa) incur a runtime penalty that's way worse than calling JavaScript functions from JavaScript.
Can you provide a source for this? I've never heard it and, though it may be correct, this would make wasm much less useful to me.
I have heard that accessing the DOM from wasm will be quite expensive, but that's different from just calling a function.
- gsnedders 9y agoI've not been that involved with WASM (I've been more or less out of the JS game since around the time asm.js became a thing), but AFAIK the only thing notable is JS -> WASM is more expensive than WASM -> WASM (but should be no worse than JS -> JS); WASM -> JS should be the same as JS -> JS.
- Matthias247 9y agoOne thing is pure call performance (time to invoke a void() function). I don't know where that is, but I guess for WASM<->JS it's slower than WASM<->WASM and JS<->JS, since it can't be inlined. The more important thing however is the cost of parameter passing. Let's keep in mind that WASM only support numeric types and typed arrays. So in order to make a function call from JS to WASM or the other way around which passes a string as a parameter the string needs to be converted into a format that the other side understands (Javascript string object <-> WASM typed array which contains string in UTFx format). So basically for all more complex data types crossing the boundary costs the [de]serialization of the parameters, which may be huge (and even causes allocations). If you also only work with integers and typed arrays on the JS side that does not apply. But I guess most people won't be comfortable with that.
- gsnedders 9y ago> One thing is pure call performance (time to invoke a void() function). I don't know where that is, but I guess for WASM<->JS it's slower than WASM<->WASM and JS<->JS, since it can't be inlined. …why can't it be inlined? There's no good reason why it can't be inlined.
- Matthias247 9y agoWhen I wrote about that I thought about static resolving of where inlining is possible, which would be hard on a boundary to a dynamic language. But yeah, assuming both WASM and JS run inside the same JITting VM it is probably happening.
- disordinary 9y agoThere is a significant penalty when converting types from ASM.JS or WASM to Javascript. If you stick entirely within ASM then it is much faster but the cost of interacting with JS means that it can work out being quite a lot slower. Unfortunately you need to interop with JS at the moment in order to interact with the DOM, if you do things entirely in WebGL then ASM is a lot faster.
- trgv 9y agoRight now, one of the projects I'm working on calls a wasm function which returns a pointer. I then do a lookup in the wasm buffer at the address specified by the pointer and pull out a few numbers with a float64array constructor. Is that an expensive operation?
- kannanvijayan 9y agoIt's probably best to keep a Float64Array view into the ArrayBuffer around, and use that repeatedly instead of constructing a fresh one each time. The interpreters and baseline JITs will always construct the object because they can't inline and they don't do whole-method analysis.. and the heavyweight JITs _probably would_ inline the constructor, then notice that the constructed array does not escape, then scalarize the whole thing down to a single read... but hey, why work the optimizer so hard when you can just make life easy for it and do a single allocation up front, and it runs fast in all performance tiers, and performance isn't predicated on a particular optimization strategy being utilized.
- trgv 9y agoThanks for the advice, very helpful.
- jononor 9y agoYou should ask the profiler.
- geofft 9y agoDo you still have a penalty when e.g. manipulating a TypedArray from JS? (If so, this seems like a regression compared to unoptimized asm.js.)