Component model & instantiation time · general

From what I understand the component model is a mixture of module linking + interface types, and requires that each additional module is separately instantiated. In scenarios where instantiation time is critical (Wasm instance per web request) it becomes impractical to have many modules linked together, because each addition slows down the instantiation. I'm afraid that users are going to avoid using modules linked together if it means performance sacrifices and are going to stick to always one module.

I'm curious how others are thinking about this issue and if it would have any measurable performance impact in real-world applications?

Dan Gohman (Oct 18 2021 at 14:27):

One observation here is that component linking is very intentionally being kept very simple. In a lot of use cases, dynamism like resolving URLs to satisfy dependencies, or generating code to connect two components together, will be done ahead of time, so that the actual linking that happens at instantiation time stays simple and fast.

Till Schneidereit (Oct 18 2021 at 14:27):

Fully agreed that this is a crucial point! Since we at Fastly have the same instance lifetime model, this is something we, too, care about deeply. It's also why we've spent significant effort optimizing instantiation time in Wasmtime :smile: A key enabler of good instantiation perf is the use of the pooling instance allocator. With that, instantiation is measured in (low) single-digit microseconds, which alleviates a lot of these concerns, I think :smile:

Implement simple benchmarks for instantiation. by peterhuene · Pull Request #2900 · bytecodealliance/wasmtime

This adds benchmarks around module instantiation using criterion. Both the default (i.e. on-demand) and pooling allocators are tested sequentially and in parallel using a thread pool. Instantiation...

Dan Gohman (Oct 18 2021 at 14:28):

Till Schneidereit (Oct 18 2021 at 14:28):

Dan Gohman (Oct 18 2021 at 14:29):

And, because linking is kept simple, it should be possible for engines to cache graphs or subgraphs of linked components, so that repeatedly instantiating the same set of components linked together can be very fast.

Bernard Kolobara (Oct 18 2021 at 14:39):

Thank you both! :) That's what I was also thinking, if per instance time is optimized enough it should be fine. Sacrificing a bit performance for a simpler model of linking (each module gets a separate instance) should be the way to go.

Till Schneidereit (Oct 18 2021 at 15:09):

It's not even just a simpler model of linking—it's critical to the security model Components provide. Because of that, we see it as vital to ensure we really do make the overhead low enough. Once we get to a world where component graphs grow large enough, that'll almost certainly need to involve lazy instantiation, but for the time being instantiating sets of components as Dan describes should be plenty fast

Steve Williams (Oct 18 2021 at 15:10):

given there's so much low level knowledge here, why am I fighting with this thing.

Steve Williams (Oct 18 2021 at 15:16):

or to put it a little more politely, could I get some help nailing global variable emit please. its hard. the code is terse & rust isn't my language of choice. surely you all need this too. essentials first - all bases covered, then optimisations.

Steve Williams (Oct 18 2021 at 15:29):

& appreciate other work is going on, not just the itch I think needs scratching. thanks all for vast amounts of difficult work on this project.

Stream: general

Topic: Component model & instantiation time

Bernard Kolobara (Oct 18 2021 at 14:19):