Stream: wasmtime

Topic: Speeding up Multiple Components

view this post on Zulip Mason Ginter (Mar 22 2023 at 05:48):

I'm working on a project that is essentially using web assembly components as plugins, so I have mutliple wasm components, all with the same interface. Functions like update need to be called each instance at a regular interval, so I'm looking to speed up that process. This is similar to yonil's thread from a few days ago, but different layout

  1. Each component will only have a single instance
  2. Each instance has it's own store, so components don't sharing data
  3. I'm supporting WASI, so I'm currently using part of preview2-prototyping. So I'm trying to also work around async restrictions that are there currently

Questions:
What are ways I can improve the speed?
Could creating engines/linkers per instance improve performance when running in parallel?
How can I parallelize them in an async environment?
How expensive is the instantiate_pre from wasmtime::component::bindgen!? I want it to be extensible, where a plugin can add extra binding types, so if I can leave it in that state it makes it easier to generate additional bindings. Otherwise, I can just generate the any extra bindings ahead of time.

view this post on Zulip Alex Crichton (Mar 22 2023 at 15:36):

What are ways I can improve the speed?

I think the best place to start here would be to profile the current implementation. Without a concrete idea of where the bottleneck is it's tough to recommend various options/strategies.

Could creating engines/linkers per instance improve performance when running in parallel?

This souldn't be the case. Using one engine and linker for parallel instnatiations vs many engines/linkers should be the same performance. That being said this hasn't been rigorously tested, so if profiling shows a bottleneck here, it may be a bug for us to fix.

How can I parallelize them in an async environment?

This is a very broad question that is somewhat outside of the scope of Wasmtime itself. I'd recommend taking a look at tokio which enables running futures on multiple threads and then Wasmtime's async support will plug into Tokio well.

How expensive is the instantiate_pre from wasmtime::component::bindgen!?

It's not something that has had much effort put into optimizing it. It's not intentionally slow but at the same time it's not designed to be lightning fast. The fastest operation in Wasmtime is to acquire an InstancePre<T> and then instantiate it. That's tried-and-true and is the go-to method of instantiating something quickly. The general idea is for InstancePre<T> to represent pre-computed state of "everything is ready to go and all that's necessary is to create a new instance", so it's up to the application where this work goes and how to amortize it.

Last updated: Nov 22 2024 at 16:03 UTC