Consider using compileStreaming and instantiateStreaming to enable WASM caching on Node

[landonxjames]

According to this V8 blog post (which is from 2019 so might be out of date, but I couldn't find anything newer), WASM modules are only cached when using the compileStreaming and instantiateStreaming APIs. Both of these are supported by Node (implementation PR). Although MDN says Node doesn't support compileStreaming, I have tested it and it exists and works as expected. Switching to these, and ideally just using instantiateStreaming seems like it could provide substantial performance improvements in cases where users need multiple instances of the same module, or by allowing for the instantiation of modules in Worker threads.

The *Streaming APIs expect the Response type return of a fetch call, unfortunately Node's fetch doesn't seem to support getting local files yet. Thankfully it is possible to manually construct a Response object with a Content-Type: application/wasm header that is accepted by the APIs.

[guybedford]

The fetchCompile function used by JCO uses compileStreaming - https://github.com/bytecodealliance/jco/blob/main/crates/js-component-bindgen/src/intrinsics.rs#L131, which should exactly benefit from this.

[landonxjames]

I think it only does that on non-Node platforms though? This chunk seems to branch do the the non-streaming compile on Node.

jco/crates/js-component-bindgen/src/intrinsics.rs

Lines 136 to 139 in c6e16b0

	if (isNode) {
	_fs = _fs || await import('fs/promises');
	return WebAssembly.compile(await _fs.readFile(url));
	}

Realized that was not really specified in the issue title so edited that in.

[guybedford]

Yes, but Node.js doesn't have any network cache to share the Wasm compilation like browsers do, which is the layer at which this behaves anyway. If Node.js did support that we could certainly revisit this.

[landonxjames]

Ahh that is unfortunate, well appreciate the explanation and will close this out