Plugin file size - compilation tips

[joepio]

The compiled example plugin weighs in at 1890KB, with --release and lto = true and opt-level = 's' (see more binary size tips here)

For my usecase, a small binary size would definitely help, as I'm aiming for low-end hardware, and I'd like to retain the instantiated WASM Runtimes in memory.

Tools like twiggy can help provide insight into how wasm binary sizes can be reduced:

        556884 ┊    28.17% ┊ custom section '.debug_str'
        370760 ┊    18.75% ┊ custom section '.debug_info'
        282045 ┊    14.27% ┊ custom section '.debug_line'
        182604 ┊     9.24% ┊ custom section '.debug_pubnames'
        165472 ┊     8.37% ┊ custom section '.debug_ranges'

That's about... 75% for debugging stuff? Should not be included in the --release binary, I think.

Others who used wasm-pack didn't have these included in binaries, but that means using a different build process. Not sure if that makes sense for this project. Also, I'm not sure if this is an fp-bindgen issue, technically. But still, it may make sense to explore how best to deal with and mention it in the docs.

Edit: Running wasm-pack build creates a 307kb .wasm file, partially by stripping the debug stuff mentioned before. That's about 80% smaller! Maybe it's a good idea to mention this in the docs?

[emschwartz]

For what it's worth, we run the wasm files through wasm-opt tool with the -Oz option (optimizing aggressively for size) after compiling them.

It probably would be worth changing the build process to reduce the size or at least give a bunch of recommendations. I'm sure many people will want small wasm modules.

[Zagitta]

Internally we followed the following guide to reduce our wasm module size: https://github.com/johnthagen/min-sized-rust
One of the biggest gains were from enabling strip. Building the std lib with size optimizations also gave another 10% improvement after that.