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

Hi!

I see that the project already uses ThinLTO in the Release profile in the root Cargo.toml file - it was introduced in this commit. However, ThinLTO is usually less efficient from the perspective of performed optimizations than Fat (aka Full) LTO. Additionally, I suggest enabling codegen-units = 1 (CG1) too. Enabling more advanced optimizations allows us to reduce the binary size further (always a good thing) and improve the application performance more.

Basically, it can be enabled with the following change:

[profile.release]
codegen-units = 1
lto = "fat" # instead of "thin"

I have made quick local tests (AMD Ryzen 9 5900x, Fedora 42, Rust 1.87, the latest version of this project at the moment, CC=clang CXX=clang++ cargo build --release -p quickwit-cli --features release-feature-set --bin quickwit command) - the results are below.

• ThinLTO (current Release profile): 188 Mib, clean build time: 3m 30s
• ThinLTO + CG1: 151 Mib, clean build time: 5m 40s
• FatLTO: 154 Mib, clean build time: 11m 16s
• FatLTO + CG1: 139 Mib, clean build time: 10m 18s

Since the Release profile is used only for release binaries, this build time increase shouldn't be a problem for the project. I think you can afford build time increase on CI if it provides more optimized Quickwit for users. Top memory consumption for FatLTO during the build was around 12 Gib. It's a huge number but still acceptable for build farms, IMHO.

I didn't perform performance measurements (I'm not sure how to do it properly since I have much less domain knowledge than Quickwit devs) but I expect FatLTO + CG1 is also the most performant Quickwit version.

Thank you.

Start in the root Cargo.toml Release profile and review the release build command shown in Dockerfile at the linked line. Test the proposed Fat LTO and codegen-units settings with cargo build --release -p quickwit-cli --features release-feature-set --bin quickwit, comparing build success, binary size, build time, and resource use against the current profile.