Binary size, debug info, libunwind


I did a few experiments regarding the binary size of a very small program. Initially I was worried how much space the symbols of libunwind occupied when analyzed with bloaty. But the results are interesting in other ways and I don’t understand them entierly.

The Program:

fn main() {
    println!("Hello World!");

And the profile in Cargo.toml

panic = "abort"
lto = true
codegen-units = 1
incremental = false

panic = "abort"

I compiled the program in four configurations: stable and nightly installed using rustup. Then I compiled rust myself with the default config.toml -> backtrace. After that I set backtrace=false in config.toml -> nobacktrace

debug debug & stripped release release & stripped
stable 3,9M 419K 2,0M 387K
nightly 2,4M 195K 845K 167K
backtrace 308K 195K 194K 159K
nobacktrace 209K 111K 105K 79K

If you want to have a look yourself, here are the binaries:

  • In stable I think a substantial part of the extra size results from jemalloc.
  • nightly and backtrace should have a similar size because they have similar source versions. For the stripped binaries this is the case, but there seems to be a lot of extra debug information in the program compiled with the nightly version. Is this intentional and what is it good for?

I really like the size reduction when compiled with backtrace=false. Maybe it makes sense to give this option without recompilation.

What do you think?

1 Like