Hacker News new | past | comments | ask | show | jobs | submit login

That’s gorgeous. How much bigger does it grow if you heap allocate? Does it include 2mb of extra code like in normal desktop builds?



This Rust code [1] heap allocates some things (e.g., a string with `String::from`), and results in this [2] WASM file, which is 65kB, or 25kB after `gzip -9`.

[1]: https://github.com/killercup/wasm-experiments/blob/bf3b30eed...

[2]: https://github.com/killercup/wasm-experiments/blob/bf3b30eed...


Thats much smaller than I expected, especially given how large rust native binaries usually are. What allocator does that use? Does that 65k include its own malloc implementation like we needed for asmjs, or does WASM expose a system malloc library or something?


wasm exposes "memory sections", which the module states up-front how much it wants. It can also generally call a "grow memory" function that makes this space bigger. That's it, from the direct wasm perspective.

That said, this target uses https://github.com/alexcrichton/dlmalloc-rs


It should be possible to reduce that a bunch more, 65kB sounds high.

Running the binaryen optimizer on that wasm shrinks it by 6%. Probably more can be done on the Rust side.


Absolutely, yeah. Having a real linker will help with that as well. Until then, you can also compile with

    [profile.release]
    opt-level = "s"
(i.e., optimizing for size), to get it down to 23kB gzipped.


I’m away from my computer right now, so may take a while to give you an exact number, but when I first did this, I forgot to turn on optimizations, and the libstd version was 173kb pre-gzip. So I’d imagine it’s similar to that, or at least, that gives you an order of magnitude.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: