Enable Link-Time Optimization (LTO)

[zamazan4ik]

Hi!

I noticed that in the root 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 (in this case, it's not critical at all but anyway).

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 release-lto (actual naming is completely up to you) profile where additionally to regular release optimizations LTO also will 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 also should help).

If you are ready to invest more resources into improving the project's overall performance, I can suggest taking a look at Profile-Guided Optimization (PGO) and Post-Link Optimization(PLO) - I write about them a lot in my repo: https://github.com/zamazan4ik/awesome-pgo (and this article).

Since the project lacks development resources, I suggest starting with LTO for now and moving PGO/PLO work to the backlog (IMHO).

Thank you.

[jgarzik]

Thanks for your thoughts, and welcome!

LTO: This is nice-to-have. I have already experimented with it. It produces good code size gains. No apparent performance gains, though I did not measure tightly.

The drawback with this project: posixutils covers over 150 binaries. LTO x 150 adds notable build time to the release build.

PGO: We would like to do this. I think the main issue is creating a test corpus, and then running against that corpus to create the profile data.

PLO: This is new to me. It sounds worth researching.

[zamazan4ik]

LTO: This is nice-to-have. I have already experimented with it. It produces good code size gains. No apparent performance gains, though I did not measure tightly.

Yeah. From my experience, LTO performance gains in many situations are nearly evenly distributed across programs so no they can be "hidden". Code size gains are also important, anyway - smaller binaries lead to slightly faster startup plus reduces requirements for storage (embedded case first comes to my mind).

The drawback with this project: posixutils covers over 150 binaries. LTO x 150 adds notable build time to the release build.

Yep, I agree. We can try to mitigate it somehow. E.g. what if we will build with LTO not for each Release but let's say "each N commits" or just per release (if you have prebuilt binaries)? Another question - did you use Thin or Fat LTO? ThinLTO has lower build time overhead (in the price of a bit less aggressive optimizations but in practice it's fine). If we have two different profiles, a user at the very least will be able to choose: do they want to wait some additional time for LTO or just don't use it? My assumption is that in most cases for posixutils in practice, it's completely fine to wait a bit more during the build phase for release builds.

PGO: We would like to do this. I think the main issue is creating a test corpus, and then running against that corpus to create the profile data.

Totally agree. I didn't see a good target workload benchmark/test suite for training PGO for posixutils (and similar projects like uutils).

PLO: This is new to me. It sounds worth researching.

I can recommend starting reading about it here. The most used tool for PGO nowadays is LLVM BOLT.