Feature request: Show effectiveness of each step

[joshuafriedrick]

Would be nice to grab a couple random crates and measure average binary size changes for each step and list those as well.

[johnthagen]

I agree that would be nice information. I would ideally like that to be in a blog post we could link to min-sized-rust since the results will depend heavily on the exact code that is compiled.

It would also be neat to see the negative effects as well: i.e. how much does execution and compilation speed decrease as these size-reducing techniques are applied.

[soc]

Not sure if it's useful for you, but I wrote down some measurements for my crate for each step here: https://github.com/dirs-dev/dirs-cli-rs/blob/main/Cargo.toml

I'm currently updating the crate, so some of the numbers are out of date until I can get things to compile again. I. e. cargo +nightly build -Z build-std=std,panic_abort -Z build-std-features=panic_immediate_abort --target i686-pc-windows-gnu --release described here and here (same for x86_64) fails with

error: linking with `i686-w64-mingw32-gcc` failed: exit status: 1
/usr/bin/i686-w64-mingw32-ld: cannot find rsbegin.o: No such file or directory
/usr/bin/i686-w64-mingw32-ld: cannot find rsend.o: No such file or directory

[johnthagen]

@soc Thanks!

I think a nicely written Gist or a blog post is what I'd be looking for if we wanted to link to some real world numbers.

But either way, interested users can find your comment here too and look at the numbers you've posted in your Cargo.toml as well.

[soc]

@johnthagen I'll look into that after I manage to sort out my issues ... do you have an idea what's going on with those missing rsbegin/rsend files maybe? It worked on older nightlies.

[johnthagen]

@soc do you have an idea what's going on with those missing rsbegin/rsend files maybe?

No, I haven't worked with the i686-pc-windows-gnu much. Usually I target msvc. You could try asking for help at https://users.rust-lang.org/

[soc]

Thanks, no worries! (Doesn't msvc require running Windows?)

[johnthagen]

I assumed you were trying to build on Windows given the i686-pc-windows-gnu target. I didn't realize you seem to be trying to cross compile to that target? But in any case people on the users forum would have a much better time helping you 😄.

[fhars]

opt-level = 'z' may not be your best bet when trying to shrink your program, here are some of my numbers for the text size for a small thumbv6m-none-eabi binary depending on opt-level:

0: >32k (linker failure)
1: 15616
2: 11560
3: 11524
s: 10816
z: 13048

[correabuscar]

interesting...

opt-level

The opt-level setting controls the -C opt-level flag which controls the level of optimization. Higher optimization levels may produce faster runtime code at the expense of longer compiler times. Higher levels may also change and rearrange the compiled code which may make it harder to use with a debugger.

The valid options are:

0: no optimizations
1: basic optimizations
2: some optimizations
3: all optimizations
"s": optimize for binary size
"z": optimize for binary size, but also turn off loop vectorization.

It is recommended to experiment with different levels to find the right balance for your project. There may be surprising results, such as level 3 being slower than 2, or the "s" and "z" levels not being necessarily smaller. You may also want to reevaluate your settings over time as newer versions of rustc changes optimization behavior.

from: https://doc.rust-lang.org/cargo/reference/profiles.html#opt-level

[johnthagen]

For those interested, I posted in IRLO to see if those more knowledgeable than me can help provide insights on what/how we should recommend "s" vs "z" opt-level:

• https://internals.rust-lang.org/t/should-default-recommended-opt-level-for-minimizing-binary-size-be-s-or-z/19685

[johnthagen]

@fhars Thanks for brining this up. I updated the guide to mention this

• 9285dda