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
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.
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: Dec 23 2024 at 13:07 UTC