release build produces big binary for wasm32-unknown-unknown target

[mahdi-shojaee]

The output wasm binary for release build is 1.9M for a minimal wasm crate!
Until nightly 2018-08-13 everything was fine (119B).

I tried this code:

#[no_mangle]
pub fn init() -> u32 {
    0
}

Build command:
cargo build --release --target wasm32-unknown-unknown

I expected to see this happen:
All builds must produce small binaries.

Instead, this happened:
For toolchains until nightly-2018-08-13, cargo build produces 119B wasm output that is correct. But for the newer toolchains cargo build produces 1.9M wasm output!

Meta

rustc --version --verbose:

rustc 1.30.0-nightly (7219130 2018-08-26)
binary: rustc
commit-hash: 7219130
commit-date: 2018-08-26
host: x86_64-apple-darwin
release: 1.30.0-nightly
LLVM version: 7.0

[CryZe]

The names for all the non-exported functions are now included again. You need to pass --strip-debug to the linker in order to remove them. However that also means a lot of the tooling doesn't work properly anymore.

Actually, considering you only have that single function, I'm not sure why it would include all the other garbage. Do you have LTO active?

[mahdi-shojaee]

@CryZe I have not activated LTO. If I activate it the binary size will be 54k which is large again for this minimal code compared to 145B with LTO enabled and 119B without LTO enabled on nightly-2018-08-13.

[CryZe]

It seems like there's just a whole lot of debug info in there now that no tool seems to be able to strip away:

 ;; custom section ".debug_info", size 48058
 ;; custom section ".debug_macinfo", size 2
 ;; custom section ".debug_pubtypes", size 20551
 ;; custom section ".debug_ranges", size 9944
 ;; custom section ".debug_abbrev", size 1269
 ;; custom section ".debug_line", size 22427
 ;; custom section ".debug_str", size 54517
 ;; custom section ".debug_pubnames", size 17517

[CryZe]

Apparently you can only have either both name sections + debug info or none atm: #53434
So they opted for enabling both for now.

[alexcrichton]

Ah thanks for the report @Mehdishojaei! As @CryZe pointed out though this is all debuginfo so it shouldn't affect the size of the final wasm binary. This is similar to the story on Linux where release binaries by default have debuginfo for the standard library. We can try to remove the sections automatically when LLD has support for doing so but we may not wish to do so by default (still undetermined)

In the meantime tools like wasm-gc and wasm-bindgen should automatically remove the dwarf debug info (with options to preserve it if you'd like). I suspect that tools like wasm-opt will also grow options over time to remove this, and additionally bundlers like webpack will learn to remove these by default.

[CryZe]

@alexcrichton Is this a new feature in wasm-gc, because it doesn't get removed with my slightly old-ish wasm-gc build.

[alexcrichton]

It is indeed!

[mahdi-shojaee]

@CryZe, @alexcrichton Thanks for your answers, Yes I know great tools wasm-gc and wasm-bindgen. But I still cannot understand why this huge debug info included after 2018-08-13? especially for this code that has no dependencies or even not used any module (String, ...)! It's all the crate code:

#[no_mangle]
pub fn init() -> u32 {
    0
}

For bigger wasm crates the size difference relative to nightly-2018-08-13 version will grow, event with wasm-gc and LTO.

[alexcrichton]

@Mehdishojaei this is unfortunately just how debuginfo works on the wasm target right now. None of the size is code related, it's all optimized as much as we can. Almost all of the size is debuginfo/custom section related, which is trivially removable by tools.

LLD may gain enough support to trim down dwarf information in the future, but currently it's not there yet.

[mahdi-shojaee]

@alexcrichton thanks for your clarification.