Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Build --release doesn't optimise filesize? #4122

Open
SuperCuber opened this Issue Jun 5, 2017 · 8 comments

Comments

Projects
None yet
7 participants
@SuperCuber
Copy link

SuperCuber commented Jun 5, 2017

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!

@ghost

This comment has been minimized.

Copy link

ghost commented Jun 5, 2017

I think this should only change if panic = 'abort' to avoid the backtrace getting wiped.

@SuperCuber

This comment has been minimized.

Copy link
Author

SuperCuber commented Jun 5, 2017

@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.

@alexcrichton

This comment has been minimized.

Copy link
Member

alexcrichton commented Jun 5, 2017

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.

@mati865

This comment has been minimized.

Copy link
Contributor

mati865 commented Apr 5, 2018

@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.

@matklad

This comment has been minimized.

Copy link
Member

matklad commented Apr 5, 2018

@mati865 we have a nightly rustc flag for that: rust-lang/rust#49212. I think the idea is, eventually, to enable stripping for --release by default and flip the flag's meaning to disable strip.

@mati865

This comment has been minimized.

Copy link
Contributor

mati865 commented Apr 5, 2018

@matklad that's nice but it would be even better if there was option to use --strip-all (-s) instead of --strip-debug (-S).

@jcbritobr

This comment has been minimized.

Copy link

jcbritobr commented Jul 6, 2018

Hello. When this will be solved?

@kornelski

This comment has been minimized.

Copy link
Contributor

kornelski commented Mar 15, 2019

cc #3483

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.