Enable Link-Time Optimization (LTO) for Inko

[yorickpeterse]

Discussed in https://github.com/orgs/inko-lang/discussions/769

^{Originally posted by **zamazan4ik** October 16, 2024} Hi! I noticed that in the `Cargo.toml` [file](https://github.com/inko-lang/inko/blob/main/Cargo.toml) 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](https://github.com/kbknapp/cargo-outdated/blob/master/Cargo.toml#L48). If for some distros LTO creates problems (I've seen multiple issues with LTO in AUR e.g.) - maintainers can opt out of LTO in their specific cases. Basically, it can be enabled with the following lines: ``` [profile.release] lto = true ``` I have made quick tests (Apple M1, macOS): enabling `lto = true` reduced the binary size from 99 Mib to 91 Mib. The project also builds fine with LTO on my Linux setup (Fedora). Thank you.

[yorickpeterse]

IIRC lto = "thin" is pretty much always a better choice compared to lto = true. I however don't remember exactly what the impact is on compile times. I'm also not sure if blindly enabling this has any potential negative impact on certain platforms (I don't think so).

As for profiles: we already have a release-debug profile that I occasionally use when doing performance debugging, as the regular release profile sometimes doesn't include all the necessary debug info. While we can add release-lto, I'd rather not do so as we'll quickly end up accumulating different and rarely used profiles. Instead, I'd either leave this up to package managers entirely or enable it by default if the compile times don't increase dramatically.

[yorickpeterse]

I did a quick test on my laptop, which is an X1 Carbon Gen 7 I think:

Profile	Time	inko size	libinko.a size	Program size (unstripped)	Program size (stripped)
release	43 sec	97 MiB	31 MiB	11 MiB	3.6 MiB
release-lto	49.5 sec	67 MiB	41 MiB	11 MiB	3.6 MiB

Here release-lto is the release profile combined with lto = "thin". The program is the following simple hello world program:

import std.stdio (Stdout)

class async Main {
  fn async main {
    Stdout.new.print('hello')
  }
}

So using lto = "thin", the compile times increase by 15%, while the executable size is reduced by 30%. Oddly enough, the size of the shared runtime library (libinko.a) increases, but the resulting executables remain the same size. For Inko's test suite I'm also not seeing a difference in the executable size.

Assuming different platforms (e.g. Arch Linux and Fedora) won't have any problems with lto = "thin" being the default, and it works with all linkers (or silently ignores it if this isn't the case, instead of producing an error), I'd be fine with enabling this for the release profile.