Peter Vetere (Jan 20 2022 at 16:26): Peter Vetere (Jan 20 2022 at 16:26):Hi! I'm wondering if there is a good way to estimate (or predict) the size of a compiled Wasm module. In the product I work on, we need to adhere to memory constraints set by the user. I realize there are likely many factors involved in determining a compiled module's size, including the code's actual behavior, and whether debug information is included. But, still, is there a way to get a ballpark? Is the size of a serialized module a good indicator? Thanks!
Pete
Alex Crichton (Jan 20 2022 at 16:28):The size of a compiled module should be a good indicator (e.g. the output of the wasmtime compile command) of the compiled module's resident memory size later. To clarify, though, you mean the compiled code for a module, right? Or do you mean the runtime size of the heap that the wasm module is allowed to use?
Peter Vetere (Jan 20 2022 at 16:47):Right -- I just mean the static, compiled code for a module. Using wasmtime compile works for me. Thank you for your help!
Alex Crichton (Jan 20 2022 at 16:55):It's worth pointing out that there's also various settings which can affect the compiled module's size. For example as you've seen you can either include or exclude debuginfo. There was also a recent optimization to drop one of the largest sections optionally (.wasmtime.addrmap) which makes backtraces less precise but can be large in savings. Other codegen options like --consume-fuel also can inflate the size of the compiled code.
Last updated: Nov 22 2024 at 16:03 UTC