Use WebAssembly.instantiateStreaming instead of WebAssembly.compileStreaming

Unfortunately there are performance issues with WebAssembly.compileStreaming on iOS. On iOS devices, there is a limited amount of faster memory. Because of this, the engine doesn’t know which kind of memory to compile for until instantiate is called.

If I understand correctly, for the JSC engine compileStreaming will just do a memcopy of the .wasm. It’s only when instantiate is called that the Memory object is created. Then the engine knows whether it will be using the fast memory, or just a normal malloc’d Memory that needs bounds checks. At this point, it can generate the code appropriately.

Because of this, we plan to recommend that all bundlers use instantiateStreaming instead. Does this cause any issues for webpack?

[sokra]

This is fixed. We now use instantiateStreaming when possible. Falling back to compileStreaming + async instantiate for WASM-to-WASM dependency chains.

Falling back non-streaming variants when streaming is not supported by the browser.

[flagxor]

Raising new Instance higher than new Module might make sense.

Though we’d need to be thoughtful about leaving latitude for different implementation strategies (like compile at instantiate). Lowering the limit once it’s been raised would be hard. It seems like for modules, being able to use instantiateStreaming is ideal.

Could it be done with a console.warn to inform devs, instead of a hard fail for those situations?

In general, I’ve been encouraged to have less chatty things on the console by devtools folks. Not sure this is always ideal. I often wish we had similarly verbose compilation and caching info to Firefox for asm.js/wasm. Though for this one it might make sense.