However, execution is just one metric that might be of importance.
For example, Wasmi's lazy startup time is much better (~100-1000x) since it does not have to produce machine code. This can result in cases where Wasmi is done executing while Wasmtime is still generating machine code.
Old post with some measurements: https://wasmi-labs.github.io/blog/posts/wasmi-v0.32/
Always benchmark and choose the best tool for your usage pattern.
I guess it's like v8 compared to quickjs.
Anyway all this talk about wasm makes me want to write a scriptable Rust app!
I guess not much can be done at the moment: dependencies are often the primary obstacle in porting crates to new targets, and just comparing the list of dependencies of wasmtime vs wasmi gives a pretty good indication of which crate is a bit more careful in this regard:
https://crates.io/crates/wasmtime/33.0.0/dependencies https://crates.io/crates/wasmi/0.47.0/dependencies
That's great to hear! I think it is a bit too early to spend extra effort on porting Wasmtime to Motor OS at the moment, as there are a couple of more pressing issues to sort out (e.g. FS performance is not yet where it should be), but in a couple of months I may reach out!
What are the min memory requirements for wasmtime/cranelift?
I have run wasmtime on the esp32 microcontrollers with plenty of ram to spare, but I don’t have a measurement handy.
https://github.com/bytecodealliance/wasmtime/blob/main/pulle...