Enable Link-Time Optimization (LTO) and codegen-units = 1 for Release builds

[zamazan4ik]

Hi!

I noticed that in the 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 CPU performance a bit due to more aggressive compiler optimizations. Additionally, codegen-units = 1 (CU1) option can help too in a similar to LTO way, so I recommend to enable it as well. Right now, these optimizations are enabled only for the WASM builds - let's try to enable them for other target platforms too.

I recommend enabling LTO only for Release builds so developers experience won't be affected by the increased build time. Actually, I can propose to use flags directly from this ripgrep profile (like stripping and other things) - or just copy your WASM profile.

Basically, it can be enabled with the following lines to the root Cargo.toml file:

[profile.release]
codegen-units = 1
lto = true # FatLTO - the most aggressive LTO version
<possible other options like strip = true and others>

I have made quick tests (AMD Ryzen 9 5900x, Fedora 43, Rust 1.94, cargo build --release --bin ggsql --bin ggsql-jupyter and maturin build --release build commands, without stripping) - here are the results:

Profile / Binary name	ggsql	ggsql-jupyter	lib_ggsql.so (from maturin build)	Wheel size
Current Release profile	144 Mib	146 Mib	133 Mib	36 Mib
Release + FatLTO + CU1	111 Mib	113 Mib	102 Mib	33 Mib

Clean build times for binary targets:

• Current Release profile: 3m 44s
• Release + FatLTO + CU1: 8m 51s

Clean build times for the wheel:

• Current Release profile: 3m 12s
• Release + FatLTO + CU1: 7m 55s

Even if build time increase is kinda significant - I think it's an acceptable tradeoff since we can enable it for the Release builds, so all Release binaries (including the prebuilt one from the GitHub Release page), will be more optimized by default. Memory consumption is also increased during the LTO phase but it's still should be fine for GitHub actions and should not exceed it's limit.

Thank you.

[thomasp85]

Agreed, we should do that for the next release

[georgestagg]

On the Linux GitHub containers, at least when we were compiling in polars, we are pretty close to the limits on memory pressure. It is a property of the linker, macOS handles it much better.

We should do a test run on the GitHub runners before merging the change proper. If it is too much, we can add swap, but that is slow.

At least we have shorter compile times now, it would have been harder to justify if we were still waiting 30+ mins for a build.