David Sherret (May 28 2020 at 04:24): David Sherret (May 28 2020 at 04:24):In wasmer I can compile a wasm file's bytes and save them to a file. This means I can get super fast startup times after the initial compile on the first run. Is there something similar in wasmtime or does the wasm file need to be compiled each time? Based on the rust docs it doesn't seem like it, but maybe I'm misreading. Thanks!
Dan Gohman (May 28 2020 at 04:33):In wasmtime you can enable compilation caching by calling Config::cache_config_load_default.
Dan Gohman (May 28 2020 at 04:33):In the CLI, caching is enabled by default
David Sherret (May 28 2020 at 04:37):Oh, I see. Thanks! So this is the config for the engine that's used to create the store and then the module. So I think that means I have to keep around the original .wasm file bytes and let this do the caching for me?
David Sherret (May 28 2020 at 04:39):What would be nice is if I only had to cache and keep around the compiled bytes and throw away the wasm file's bytes. I would like to just say "here's the compiled bytes... use them" and do my own caching. If I'm correct that this isn't possible then I think I'll open an issue because I don't see one
Till Schneidereit (May 28 2020 at 10:17):This is something we want to support, yes. We'd like to completely separate compiling and execution in the runtime in such a way that the execution part doesn't have to know where the compiled code comes from.
There are some open questions around how best to expose this. E.g., should we generate full proper .so files like lucetc does, or something else? And how would we expose this in a way that'd enable the use case you describe, while making the more common case work transparently?
David Sherret (May 28 2020 at 14:11):I opened https://github.com/bytecodealliance/wasmtime/issues/1779 with an example of how wasmer does it
Last updated: Dec 23 2024 at 12:05 UTC