Enable Link-Time Optimization (LTO)

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

I suggest enabling 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. If you think that a regular Release build should not be affected by such a change as well, then I suggest adding an additional dist or release-lto profile where additionally to regular release optimizations LTO will also be added. Such a change simplifies life for maintainers and others interested in the project persons who want to build the most performant version of the application. Using ThinLTO should also help to reduce the build-time overhead with LTO. If we enable it on the Cargo profile level, users, who install the application with cargo install, will get the LTO-optimized version "automatically". E.g., check cargo-outdated Release profile.

Basically, it can be enabled with the following lines:

[profile.release]
lto = true

Thank you.

[poliorcetics]

Meh. Unless I see a benchmark showing clear improvement, LTO would just worsen compile times for no gain since we're mostly doing file and network operations: LTO cannot make them go faster.

Additionally, if package maintainers for a distro want to enable LTO, they should use CARGO_PROFILE_<name>_LTO to affect every crate without needing patches.

[zamazan4ik]

Unless I see a benchmark showing clear improvement, LTO would just worsen compile times for no gain since we're mostly doing file and network operations: LTO cannot make them go faster.

I agree that from the performance perspective, LTO shouldn't bring measurable improvements in this case (however, I guess buffrs lint performance can be improved by it). If you have a good bench suite for that, I can perform quick tests - no problem.

However, LTO helps with reducing the binary size. With lto = true the buffrs binary size dropped from 13 Mib to 9.8 Mib. At least from the size perspective, I see improvements. Regarding build times: on my AMD Ryzen 9 5900x I got 28s for non-LTO and 58s for the Fat LTO builds. I think it's still acceptable since the tool won't be compiled too frequently, and such an increase is acceptable for CI systems too (IMHO). If for someone it's not okay (like building on REALLY constrained build machines) - then such users can opt-out LTO. I suggest increasing the default optimization level for all users with this change. The final decision of course is up to you :)

Additionally, if package maintainers for a distro want to enable LTO, they should use CARGO_PROFILE__LTO to affect every crate without needing patches.

Here we have several details. Firstly, in this case, users won't get an LTO-optimized version via cargo install - not all people install Rust apps via system package managers. Secondly, sometimes maintainers afraid of enabling optimizations that are not enabled by an upstream (on the link the talk is about PGO but the case is still valid). So turning on LTO in the upstream increases trust in LTO for the application from the maintainers' perspective too.

[qsantos]

Additional data point with a 7950X3D: 14s → 44s (Amdahl's law), 13 MB → 11 MB

Also, stripping symbols reduces the binary size to 9.8 MB and 8.6 MB respectively.