Loading precompiled modules is slower than necessary #3230
Description
Currently today loading a precompiled module from disk or some other location is actually a relatively slow task in Wasmtime. While much faster than compiling a module, we can do much better! I'm going to open this meta-issue for those interested in tracking some progress I'm doing here. Over the next week or so I'm going to open PRs which migrate Wasmtime towards a more "mmap-and-go" approach where all we need to do to load a module is to mmap it into memory, no copies necessary.
Currently as-is of the time of this opening we're pretty far away from this world. On my quick-and-dirty branch to implement this I'm seeing a roughly 10x improvement in load times for precompiled modules. While this doesn't have every possible improvement, it's a lot further than where we are today!
My general goal for where I'm going to go with this refactoring is:
- Decode far less data with
bincodeitself - Most data is usable as-is from the on-disk format, no deserialization necessary
- Heavy usage of
objectas a crate and the ELF file format. While not strictly necessary theobjectcrate has lots of nice utilities and I think this also makes us more amenable in some possible future to generate raw object files usable for linking. Additionally I think it's extremely useful to be able to inspect the raw output of compliation with standard tools likeobjdump, which cannot be done today. - Far fewer copies of data between places. The main goal is that there should be one "source of truth" for a module which is the only location a module's data resides in.
Lots more details will be apparent as I open PRs and we debate the finer points, of course. For those intersted in the existence of PRs feel free to subscribe to this issue and I'll post individual PRs here, and that way you don't have to get all the review noise necessarily.
cc @fitzgen, @peterhuene, @cfallin