Allow multiple instances of the same named import (e.g. javy_quickjs_provider_v2)

[bep]

Is your feature request related to a problem? Please describe.

This is a more concrete follow up to #2293. Currently it's only possible to have one instance of a named import, so if you want multiple instances that requires the same import, you need to create multiple runtimes.

Describe the solution you'd like

I guess there are many ways to go about this, one way could possibly be a new module config option, e.g.

namedImports := map[string]api.Module{
   "javy_quickjs_provider_v2", myQuickJsInstance,
}
wazero.NewModuleConfig().WithNamedImports(namedImports)

Describe alternatives you've considered

I tested out 2 options:

1. One runtime per script (with a shared compilation cache)
2. Having the QuickJS runtime embedded in the JS script wasm.

The benchmark below shows the two options compared. The motivation in the case below is speeding up the relatively slow Katex by throwing more threads at it, but different scripts needing the QuickJS import will end up with the same problem.

Embedding the QuickJS runtime makes the startup much more effective, but

1. The wasm files gets much larger (katex.wasm from 450 kb to 4.5 MB)
2. It makes it very unpractical if we want to embed the QuickJS runtime and have end users provide their plugin wasm files.

name                          old time/op    new time/op    delta
KatexStartStop/PoolSize1-10     19.2ms ± 6%    20.8ms ± 5%     ~     (p=0.057 n=4+4)
KatexStartStop/PoolSize8-10      116ms ± 4%      23ms ± 3%  -80.16%  (p=0.029 n=4+4)
KatexStartStop/PoolSize16-10     222ms ± 3%      32ms ± 5%  -85.58%  (p=0.029 n=4+4)

name                          old alloc/op   new alloc/op   delta
KatexStartStop/PoolSize1-10     12.2MB ± 0%    11.4MB ± 0%   -7.01%  (p=0.029 n=4+4)
KatexStartStop/PoolSize8-10     97.9MB ± 0%    49.5MB ± 0%  -49.43%  (p=0.029 n=4+4)
KatexStartStop/PoolSize16-10     196MB ± 0%      93MB ± 0%  -52.46%  (p=0.029 n=4+4)

name                          old allocs/op  new allocs/op  delta
KatexStartStop/PoolSize1-10      18.1k ± 0%     25.8k ± 0%  +42.74%  (p=0.029 n=4+4)
KatexStartStop/PoolSize8-10       144k ± 0%       32k ± 0%  -77.61%  (p=0.029 n=4+4)
KatexStartStop/PoolSize16-10      289k ± 0%       40k ± 0%  -86.20%  (p=0.029 n=4+4)

[mathetake]

@bep thanks for the proposal. Are you in the Gophers slack? There's a relatively large community in #wazero channel and I think if you share your thoughts there, people there might hop into the discussion with you.

[bep]

@mathetake I feel the discussion on Slack is drifting away from the problem at hand. I need some kind of conclusion on this to decide if I can continue down this path or if I need to look at alternatives.

Would a PR with this new config option be a likely merge if done properly (with tests et all)?

namedImports := map[string]api.Module{
   "javy_quickjs_provider_v2", myQuickJsInstance,
}
wazero.NewModuleConfig().WithNamedImports(namedImports)

[mathetake]

wazero never breaks API which is our promise, so I won't accept in the public API (except experimental/ package) until multiple people actually start using it. At best at this point, under experimental package would be the way, but I am still not convinced if that's really necessary as per the discussion in slack.

[mathetake]

having said that, I think if that's in experimental, I am ok with it for now

[bep]

OK, so with the help of the people in the Wazero Slack channel, we got to the bottom of my main performance problem of this, to summarise for others scratching their heads about the same:

• With the compile cache set on the runtime you still end up doing lot of work (about 10ms per cached compilation in my case).
• The return of Runtime.CompileModule isn't scoped to the runtime even if the method placement suggests so and the GoDoc does not mention it.
• This makes it possible to implement a local cache (e.g. map[string]wasi.Module) and work around most of the performance issues.

My benchmarks still suggests that having a runtime per instance is more (memory) costly and it feels unneedingly clunky, so I still think my suggestion above, simple as it is, makes sense to add.