If you want to skip the docker build
app.wasm.gz

If I understand this correctly, there is very little "actual" webassembly here. This is still running a node http server, in a very roundabout fashion. What I believe you are seeing is the js-wasm transfer overhead.

/cc @neelance

I bet a good portion of it is due to the setTimeout here:

@neelance I played around to see if I can shave off time.

Removing setTimeout didn't change too much. I ran it through chrome profiler and it seems the hotspot is loading strings out of the memory blob and decoding them on the js side. The strings in my example on the method names i want to call on my js values.

Perhaps some sort of constant pool is in order?

Perhaps some sort of constant pool is in order?

Maybe. We might even need some additional type like this:

idFoo := js.ID("foo")
for i := 0; i < 1000000; i++ {
   v.CallByID(idFoo)
}

This way, we could avoid referencing a method by string each time.
But we should wait with this until WebAssembly has its improved JS interop features ready.

That would be cool!

I dont know how safe this is but I changed loadString in the wasm_exec to have a js side string cache. Its not bombing... and now im getting 8-10k requests/second, vs original implementation 5540.49.

const strCache = {};
const loadString = (addr) => {
	const saddr = getInt64(addr + 0);
	const cache = strCache[saddr.toString()];
	if (cache) {
		return cache;
	}
	const len = getInt64(addr + 8);
	const ret = decoder.decode(new DataView(this._inst.exports.mem.buffer, saddr, len));
	strCache[saddr.toString()] = ret;
	return ret;
}

This will now fall under #32591. Closing this in favor of that.