Enable Link-Time Optimization (LTO) and codegen-units = 1 for cargo-c itself

[zamazan4ik]

Hi!

I noticed that in the Cargo.toml file Link-Time Optimization (LTO) for the project is not enabled. I suggest switching it on since it will reduce the binary size (always a good thing to have) and will likely improve the application's performance a bit (however, it's not so important here). If you want to read more about LTO and its possible modes, I recommend starting from this Rustc documentation.

I think you can enable LTO only for the Release builds so as not to sacrifice the developers' experience while working on the project, since LTO consumes an additional amount of time to finish the compilation routine. In this case, we can create a dedicated [profile.optimized-dev] profile where LTO will be disabled (so developers experience will not be affected). If we enable it on the Cargo profile level for the Release profile, users, who install the application with cargo install, will get the LTO-optimized version of the app "automatically". E.g., check cargo-outdated Release profile. You also could be interested in other optimization options like codegen-units = 1 - it also brings improvements over the current defaults.

Basically, it can be enabled with the following lines to the root Cargo.toml file:

[profile.release]
codegen-units = 1
lto = true

I have made quick tests (AMD Ryzen 9 5900x, Fedora 42, Rust 1.87, the latest version of the project at the moment, cargo build --profile release-strip command) - here are the results:

Build config\Binary name	cargo-capi	cargo-cbuild	cargo-cinstall	cargo-ctest
Release	27 Mib	26 Mib	26 Mib	27 Mib
Release + CG1 + FatLTO	22 Mib	21 Mib	21 Mib	22 Mib

Clean build time:

• Release: 1m 13s
• Release + codegen-units = 1 + Fat LTO: 3m 42s

Thank you.

[lu-zero]

thinlto should be even nicer.

this is something that I'd leave to the packagers or user caring about it since 3x time for a ~20% size reduction is a tradeoff people might not want to do. But definitely is worth adding it in the CI releases.

[zamazan4ik]

thinlto should be even nicer

It depends on the point of view. ThinLTO makes LTO faster during the compilation process but performs less efficient optimizations compared to FatLTO. So, if you want to achieve the best optimization as possible and you have resources for that (like doing it on CI only for releases) - FatLTO should be your choice.

this is something that I'd leave to the packagers or user caring about it since 3x time for a ~20% size reduction is a tradeoff people might not want to do

This a "opt-in vs opt-out" question. Right now, LTO is opt-in for the project, I am proposing to change this to "opt-out". Users or packagers, who really don't want LTO, can always disable LTO. The final decision of course is up to you ;)

But definitely is worth adding it in the CI releases.

Completely agree with you.

[lu-zero]

Did you check the result of thinlto? at least in some situation it seems to surpass fatlto.

[zamazan4ik]

I've performed a bunch of additional tests. The build command is the same - cargo build --profile release-strip.

Build config\Binary name	cargo-capi	cargo-cbuild	cargo-cinstall	cargo-ctest
Release + CG1	23 Mib	22 Mib	22 Mib	23 Mib
Release + ThinLTO	27 Mib	26 Mib	26 Mib	27 Mib
Release + CG1 + ThinLTO	23 Mib	23 Mib	23 Mib	23 Mib

Clean build time:

• Release + CG1: 2m 36s
• Release + ThinLTO: 1m 45s
• Release + CG1 + ThinLTO: 3m 05s

[lu-zero]

Thank you, adding opt-level = "s" in the mix seems to lead to the most gains. this evening I'll update release-strip.

[lu-zero]

https://github.com/lu-zero/cargo-c/commit/96a0b5642740d1be5e2882ecd9aa560940cfbfed this should address most of the needs.