Hi all, I have not yet advanced very deeply into the wasmtime codebase, but we are currently building a little runner agent for wasm programs that leads us to believe that there is some interesting performance optimization going on that we don't fully understand. I'd appreciate any pointers that would help us understand what is going on here.
We have a little ruby.wasm Hello world that looks like this when run via Wasmtime:
$ time wasmtime build/ruby-example.wasm
Hello, world! This is Ruby. ๐ฅ๐
wasmtime build/ruby-example.wasm 15.48s user 0.64s system 168% cpu 9.579 total
$ time wasmtime build/ruby-example.wasm
Hello, world! This is Ruby. ๐ฅ๐
wasmtime build/ruby-example.wasm 0.21s user 0.03s system 98% cpu 0.237 total
...clearly there is some caching going on.
Running our own test runner (which internally runs wasmtime) we get something like this:
$ time cargo run --release --bin test-runner -- ../wasm-samples/build/ruby-example.wasm
cargo run --release --bin test-runner -- 15.59s user 0.65s system 106% cpu 15.305 total
$ time cargo run --release --bin test-runner -- ../wasm-samples/build/ruby-example.wasm
cargo run --release --bin test-runner -- 15.35s user 0.62s system 167% cpu 9.553 total
Clearly there is some caching possible, but not enabled. What's the best way to get the same caching performance when using wasmtime as a module?
There's some info on the cli cache system here
https://docs.wasmtime.dev/cli-cache.html#how-does-the-cache-work
It looks like this API might correspond to it in the embedding create
https://docs.rs/wasmtime/latest/wasmtime/struct.Config.html#method.cache_config_load_default
You could look into calling precompile_module
yourself if you want more control.
https://docs.rs/wasmtime/latest/wasmtime/struct.Engine.html#method.precompile_module
There is also the wasmtime compile
subcommand.
Last updated: Dec 23 2024 at 14:03 UTC