I'd expect build --release to apply all optimisations, and one of them would be file size.
I tried two programs, a trivial "hello rust" and a trivial "hello panic". Both of their sizes were 3.8M which is pretty crazy for something that is supposed to be optimised... So I tried strip --strip-alling the executables.
Hello rust went to 372K
Hello panic went to 364K
That's a pretty huge change... The only difference in functionality I found is that RUST_BACKTRACE=1 shows a lot of <unknown>s on striped files which is to be expected, but I think that's not a real issue because the whole point of --release is that it's not supposed to be debugged, there is the normal build for that...
For now I will be strip --strip-alling all of my released executables but I really don't see a reason why build --release doesn't do it. I'd be happy to be enlightened if I missed anything though!
I think this should only change if panic = 'abort' to avoid the backtrace getting wiped.
@cedenday I don't see an issue with backtraces being wiped in --release if it's used in the way it needs to be used though. Also it gives the basic information of where the panic was (file and line number) after striping so it should give enough information to rebuild the project in debug mode and reproduce + backtrace the issue.
Thanks for the report! I think this is mostly due to the addition of debuginfo into the standard library a few versions ago, so the lion's share of strip is stripping out that debugging information. This does make sense to me to do by default! I'm not sure what the best place for that would be, though. We probably can't literally run strip because it's not very cross-platform so this would probably go into rustc assuming LLVM can handle it, but that'd likely involve a good amount of work.
@alexcrichton maybe LLVM's opt --strip-debug could be handy?
https://llvm.org/docs/CommandGuide/opt.html
For ld/lld --strip-all can be used and it gives the best results.
In my tests on Arch Linux (fairly recent toolchains) RUSTFLAGS="-C link-arg=-s" cargo build --release gave ~3% better results than running strip -s on release binary.
@mati865 we have a nightly rustc flag for that: https://github.com/rust-lang/rust/pull/49212. I think the idea is, eventually, to enable stripping for --release by default and flip the flag's meaning to disable strip.
@matklad that's nice but it would be even better if there was option to use --strip-all (-s) instead of --strip-debug (-S).
Hello. When this will be solved?
cc #3483
Should this be closed now that cargo-features = ["strip"] works on nightly?
See: https://github.com/rust-lang/cargo/issues/3483#issuecomment-631395566
Should this be closed now that
cargo-features = ["strip"]works on nightly?See: #3483 (comment)
I think not. --release flag is explicit.
Most helpful comment
Thanks for the report! I think this is mostly due to the addition of debuginfo into the standard library a few versions ago, so the lion's share of
stripis stripping out that debugging information. This does make sense to me to do by default! I'm not sure what the best place for that would be, though. We probably can't literally runstripbecause it's not very cross-platform so this would probably go into rustc assuming LLVM can handle it, but that'd likely involve a good amount of work.