Making calls to WebAssembly fast and implementing anyref(blog.benj.me)
blog.benj.me
Making calls to WebAssembly fast and implementing anyref
https://blog.benj.me/2018/07/04/mozilla-2018-faster-calls-and-anyref/
4 comments
This is great. I've been tracking down performance issues in libraries porting to wasm due to what appears to be Emscripten having to do JS calls every time a function pointer is used for the equivalent wasm dynamic call.
On that issue i've spent the last month having to also go through and remake tooling for wasm because Emscripten is still stuck in the asm.js ages and isn't at all flexibly modifiable.
On that issue i've spent the last month having to also go through and remake tooling for wasm because Emscripten is still stuck in the asm.js ages and isn't at all flexibly modifiable.
I am curious to know if this also makes calls from WASM into JS faster. One of the issues with WASM is that you need the JS DOM API, it is essentially your OS abstraction layer, so faster that is, the better WASM will be.
We've had optimizations to make wasm -> JS calls fast for a long time, and they became even slightly faster (around 10 or 15%) last year. There is a proposal to add DOM integration within wasm, so one could import DOM functions in wasm and call them directly (from wasm to C++, without a "trampoline" in JS).
JS DOM API is a bridge to a native implementation. I wish we could use DOM directly in WS. Problem is DOM calls are blocking but removing the JS layer can help.
Is there documentation on what Chrome/v8 currently does here? Could a similar optimization be ported over?
EDIT: I mean, why wouldn't that be one of the first items on the agenda of WASM? I was surprised when I found out that this seemingly isn't high on the list of priorities. If WASM is meant exclusively for high performance sections of code, it makes more sense, but that's a bit dull if you ask me. The ability to use any compiled language as a front-end language is far more interesting.