Status of LTO option

Hi Rustaceans,

By reading the forum, I discovered the lto = true in the [profile] section . This link time optimization leads to 17% performance increase on my release build [an integer number cruncher]. This is not negligible, and I wonder why, this option is false by default on release build ? I know that this option make the linking process longer but I don't think it the only reason. Can things be broken or is this option not 'stable' ?

Regards

It also significantly reduces final binary size.

As I understand it, it is mostly about the compilation time.

I confirm, the size is greatly reduced.

Yes, it probably implies longer compilation time, but I confirm that my execution time is reduced by almost 20%.

Documentation says :

 LTO can produce better optimized code, using whole-program analysis, at the cost of longer linking time.

So, why this flag is not set to true in profile release ?

I don't know how odd we are, but for me there's good reason not to default to LTO for release builds:

  • I started seeing LTO in a slightly different light when I built python on our ARMv7 platform. With LTO the build time is 2+ hours, without LTO it's roughly 15 minutes. (These differences are on the scale "I'll just go ahead and do it" vs "I need to reschedule my day").
  • While the majority of builds are debug builds, we do plenty of release builds that are fed into our test environment. Only if no problems are found do we actually release the code.

I guess we should probably start making a distinction between prodtest and release builds, where prodtest is for "production test environment", and release could be using LTO.

I think Alice is right -- but perhaps it's not clear why that is a good reason without knowing how much slower build times gets as the scale of the project grows. It scales really badly (.. for good reasons..).

With that said: If you want all your release builds to run LTO by default can't you configure that in $HOME/.cargo/config? Something like:

[profile.release]
lto = on

(Unsure if that's the section/option name).

3 Likes

Ok, it makes things clear for me: There's nothing to fear from LTO except a (very) long compilation time. I was scared by potential broken executable or another drawback.
Thanks for your answer.

LTO also requires more memory to compile, sometimes very noticably.

2 Likes

Indeed, that's a good idea! And when wanting to super-release / truly release, one can use env-vars too:

CARGO_PROFILE_RELEASE_LTO=fat cargo build --release

Also, for the sake of completeness, I am personally more interested in the difference between "thin" and "fat"/true LTO, since the idea seems to be that lto = true may not yield performance benefits that are worth the extra compilation time w.r.t. lto = "thin".

In other words, lto = "thin" may be a decent compromise.

  • Also note that lto = false does not equal lto = "off", although it is not too far off.
1 Like