Closed zamazan4ik closed 13 hours ago
Yes, I think this makes sense. (Is there any reason not to, given we don't really care about compile times for release mode?)
Would you be up for making a PR?
Is there any reason not to, given we don't really care about compile times for release mode?
I don't think so - usually, the increased build time is the biggest concern with LTO.
Would you be up for making a PR?
What's up?
Hi!
I noticed that Link-Time Optimization (LTO) is not enabled for the project. I suggest switching it on since it will reduce the binary size (always a good thing to have - especially if you already enabled
opt-level = "s"
) and will likely improve the application's performance (its CPU part). If you want to read more about LTO, I can recommend starting from this Rustc documentation.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
orrelease-lto
profile where in addition to regularrelease
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. E.g., checkcargo-outdated
Release profile.Basically, it can be enabled with the following lines:
I have made quick tests (Fedora 41, Rustc 1.82) by adding
lto = true
to the Release profile. The binary size reduction is the following:prqlc
: from 19 Mib to 16 Mibmdbook-prql
: from 16 to 14 MibThank you