Consider enabling more aggressive optimizations like Fat LTO and codegen-units = 1 for Release profile

[zamazan4ik]

Hi!

I see that the project already uses ThinLTO in the Release profile in the root Cargo.toml file. However, ThinLTO is usually less efficient from the perspective of performed optimizations than Fat (aka Full) LTO. Additionally, I decided to enable codegen-units = 1 (CG1) option to see the results. Enabling more advanced optimizations allows us to reduce the binary size further (always a good thing) and improve the application performance more. If you already considered Fat LTO earlier instead of Thin, could you please elaborate on your current choice?

If enabling Fat LTO is considered to "heavy" for the default Release profile, we can prepare one more profile like [profile.heavy-optimizations], and build the project with this profile for actual Releases. In this case, users will get a more optimized Niri version.

Basically, it can be enabled with the following change:

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

I have made quick local tests (Fedora 41, Rust 1.84, the latest version of this project at the moment) - the results are below. I show only binary size changes since it's easier to measure them compared to performance differences in this app.

• Current Release profile: 115 Mib
• Release + Fat LTO + codegen-units = 1: 91 Mib

Thank you.

[YaLTeR]

Hey, so I think these settings are more of a distro thing to set? For example, here's Fedora RPM macros making their own profile with all of these settings: https://pagure.io/fedora-rust/rust-packaging/blob/main/f/macros.d/macros.cargo#_88 So my COPRs should already have them all enabled.

I build the default release profile quite often for development and testing, so it should stay reasonably fast to build. Last time I tried fat LTO + codegen-units = 1, it took waaaaay longer. And preparing a separate profile seems somewhat unnecessary given that distros should already override it as they see fit.

[zamazan4ik]

Hey, so I think these settings are more of a distro thing to set?

Well, this topic is a bit more complicated. Currently distros don't enable LTO by default for Rust applications. E.g. Debian request - no recent activity. You Fedora example is also great - it shows that LTO is not enabled by default. So as far as I understand, your COPRs for now don't have enabled Fat LTO for the delivered to the users binaries.

I build the default release profile quite often for development and testing, so it should stay reasonably fast to build.

For development purposes I can recommend you to add a dedicated [profile.release-dev] where you can enable reasonable amount of optimizations and use this profile during development and testing (in addition to the already existing dev profile). In this scenario, an additional profile will be used by you, and the default Release profile will be used by everyone else. If any user will decide to disable LTO (or any other "heavy" thing) - they will be able to opt-out it. So, mainly speaking, it's more about "opt-in vs opt-out" choice - I am trying to convince you to use "opt-out" approach here :)

Last time I tried fat LTO + codegen-units = 1, it took waaaaay longer.

Yes, you are right - using Fat LTO for fast write-compile-test is definitely not a good thing. However, since the Release profile is used by people (and many maintainers) as a default profile for building the Release binary - enabling better optimizations in the Release profile consequently enables more optimizations to all downstream use cases (where the profile is not overridden ofc): maintainers and simple cargo install users.

[YaLTeR]

You Fedora example is also great - it shows that LTO is not enabled by default. So as far as I understand, your COPRs for now don't have enabled Fat LTO for the delivered to the users binaries.

Hm. Maybe they missed it? Other settings seem there, like codegen-units = 1 and opt-level = 3.

Heh, I went to look it up and found your own question: https://discussion.fedoraproject.org/t/link-time-optimization-lto-for-rust-packages-by-default-in-fedora/140086

E.g. Debian request - no recent activity.

Not sure applications should be responsible for this particular kind of distro issue.

For development purposes I can recommend you to add a dedicated [profile.release-dev] where you can enable reasonable amount of optimizations and use this profile during development and testing (in addition to the already existing dev profile). In this scenario, an additional profile will be used by you, and the default Release profile will be used by everyone else. If any user will decide to disable LTO (or any other "heavy" thing) - they will be able to opt-out it. So, mainly speaking, it's more about "opt-in vs opt-out" choice - I am trying to convince you to use "opt-out" approach here :)

Arguably, someone dealing with the niri repo directly is much more likely to do development, so it makes sense to default to development settings (i.e. no super-heavy LTO).

However, since the Release profile is used by people (and many maintainers) as a default profile for building the Release binary - enabling better optimizations in the Release profile consequently enables more optimizations to all downstream use cases (where the profile is not overridden ofc): maintainers

Hm, but is it really so? If you look at other widespread build systems like meson, I don't think downstream projects are expected to mess with optimization flags? Distros then set CFLAGS and have their %meson_build or arch-meson commands with customizations. If they don't yet for cargo, that seems like they just haven't caught up yet?

and simple cargo install users.

Using cargo install on a compositor like niri doesn't make much sense, so this one doesn't apply to us.

[zamazan4ik]

Thanks for the response!

Heh, I went to look it up and found your own question: https://discussion.fedoraproject.org/t/link-time-optimization-lto-for-rust-packages-by-default-in-fedora/140086

Hah, yeah! Unfortunately, I didn't get a response from anyone regarding LTO in Fedora. Maybe no one cares about LTO for Rust in Fedora? :D

If they don't yet for cargo, that seems like they just haven't caught up yet?

Exactly! That's why I am trying to push using LTO into the upstream build scripts - even if downstream build systems didn't enable LTO yet, Niri's users will still get an LTO-optimized version, regardless of current defaults in various build envs. Later, when all downstream default will be updated to the more aggressive defaults, settings in Niri's Cargo.toml file will play less important role, yes.

Anyway, I got your point of view. If you think that downstream maintainers should be more responsible about providing better optimizations to users, and changing current defaults is simply not worth it - that's fine! In this case, my questions is answered.

Once again thank you - especially for developing Niri!

[berkus]

Hi @YaLTeR my distro is LFS, and I install Rust software using cargo install niri, can you tell where in my distro configuration I could set those flags?

[YaLTeR]

You aren't supposed to cargo install niri. You'll just get a binary in a weird location, and none of the other things required to run a desktop session. So you're dealing with manual repo building anyway, at which point you can customize the build as needed.