Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Large wasm file sizes, potential causes, and how to avoid them? #5
Seems like there's some gotchas when it comes to what parts of Rust you use and how large it can cause your wasm output to be.
The current wasm output file size is 88kb before wasm-gc and 71kb after. This has been bugging me for a few days and I haven't looked into it until now.
A basic hello world I created was 17kb before wasm-gc and 103 bytes after which sounds much better.
After disabling some code, i've found a few factors that seem to heavily change the wasm output size.
I disabled a bunch of code to get down to this point. I haven't recreated a minimal example yet though.
I'll post any more findings I have here. Hoping someone can enlighten me on ways to keep the file size down and perhaps as to why indexing a vec costs so much?
changed the title from
Large wasm file sizes and potential causes
Large wasm file sizes, potential causes, and how to avoid them?
Dec 30, 2017
On the good news front Rust-the-language is more then amenable to tiny file sizes. We've had lots of examples in the past of tiny programs doing things like games, tiny microcontrollers, etc. On the bad news side though idiomatic Rust doesn't always lend itself well to tiny file sizes. In that sense if you're optimizing for file size then you'll probably not be writing "normal" Rust code but rather you'll be avoiding various things and/or trying to adhere to very specific patterns. The wasm project I've been helping has very strict size requirements and currently we're clocking in at about ~2k of Rust code gzipped, about 4k un-gzipped.
In general here's what you should do before you actually change any code:
If that's not small enough then at that point it's time to start changing code. This is where the guidelines may not be very idiomatic and can sometimes even be hard to adhere to as well. In any case...
Overall the code guidelines for writing small executables are the same as those if you're writing an embedded system (which isn't a coincidence!). We've got a lot of possibilities in libstd as well to optimize for code size (libstd AFAIK basically hasn't ever been optimized for code size) so there may be some low hanging fruit to solve in the panicking/std::fmt front.
I'd recommend having allocations/formatting/panics as much as you can in debug mode, but figuring out how to remove it all in release mode is the trick.
I was just looking into this myself and this answer popped up. That's a very good answer!
I was thinking a lot of it boiled down to items from
Compiling this project with the size optimization Alex mentioned, I observed a change from 66k in the binary to 64k.
I was also intrigued to realize that
@alexcrichton thanks for the great detail! I think I use
This sounds like a challenge! For node projects, typically
I wasn't even aware of wasm-opt. @jsonnull did you try wasm-opt too? And it only went down 2k?
I'm also using
The closest analog for Rust is