Support async instantiation in Node.js

[jeremy-code]

Since Node.js is on v8, which optimizes instantiateStreaming significantly due to caching,¹²³ async instantiation should be preferred. While Node.js doesn't support file URIs, a file system read stream can still be used as an input for instantiateStreaming, so as long as the MIME type is set correctly (this same technique is used in cosInstantiateStream).

Unidici does support using a Node.js read stream in the Response constructor (see here). I believe this means this should be valid in all Node.js environments. If there somehow is an issue (maybe in an edge environment where some Node polyfill exists, but the native web Response is still used...?), this could be fixed either by:

1. Readable.toWeb() from node:stream
2. Using fs.openAsBlob() instead (might have some weird issues on older Node.js versions since blobs used to be stored in memory in Node File-based Blob implementation nodejs/node#45188)

Let me know what you think.

Footnotes

1. https://v8.dev/blog/wasm-code-caching ↩

2. https://web.dev/articles/loading-wasm ↩

3. MDN warns "This method is not the most efficient way of fetching and instantiating Wasm modules. If at all possible, you should use the newer WebAssembly.instantiateStreaming() method instead": https://developer.mozilla.org/en-US/docs/WebAssembly/Reference/JavaScript_interface/instantiate_static ↩

[jeremy-code]

Regarding the Bun test failures, I am guessing it may be related to this issue: oven-sh/bun#33220.

[sbc100]

Are you sure that the caching is working under node and using streaming instantiation? Where is the cached code stored? How can we show that the caching is working?

We do already have an existing NODE_CODE_CACHING setting: https://emscripten.org/docs/tools_reference/settings_reference.html#node-code-caching

How does this compare to that?

[jeremy-code]

@sbc100

Here's a quick test repo https://github.com/jeremy-code/emscripten-node-test, and the Node.js trace logs do show that the events "wasm.StartStreamingCompilation" and "wasm.InitializeStreaming" are occurring. I'm not sure how to verify the code caching part works as intended, but at the very least, the aspect of "compil[ing] the WebAssembly module while the module bytes are still downloading" is definitely improving performance (screenshots below, no stream on top, streaming bottom).

It's not easy to test the code caching part since the bottleneck is Node.js already storing the file in memory (which is not much of a concern since the Wasm binary is only 151.589 KB), but in practice, this should be GC'd eventually.

As for where the cache is stored, I believe it is in memory. Per node:module documentation, it only stores CJS/MJS/TS files and in practice, with NODE_COMPILE_CACHE set, I don't see any Wasm files.

Per the link you provided, NODE_CODE_CACHING is a legacy setting and has no effect, is that true?

[jeremy-code]

I switched it from using openAsBlob to createReadStream (converted to a web stream) since Node.js seemed to handle backpressure strangely with blob.stream() (see node_trace.1.stream-blob.log, node_trace.1.stream-web.log).

I think this also makes more sense since openAsBlob is a slightly newer API (Node v19.8.0) compared to createReadStream (Node v0.1.31) and Readable.toWeb (Node v17.0.0).

Unfortunately, it looks like there is no easy fix to the Bun issue. I'm going to file a bug report and see if a fix is possible.