Re: [PATCH datacenter-manager 2/3] ui: d/rules: use thin instead of fat LTO

["Fabian Grünbichler" <f.gruenbichler@proxmox.com>]

On July 8, 2026 10:44 am, Robert Obkircher wrote:
> 
> On 08.07.26 09:12, Fabian Grünbichler wrote:
>> On July 7, 2026 11:53 pm, Thomas Lamprecht wrote:
>>> Am 07.07.26 um 16:06 schrieb Fabian Grünbichler:
>>>> On July 6, 2026 1:44 pm, Dominik Csapak wrote:
>>>>> fat LTO merges all LLVM modules into a single unit for optimizing.
>>>>> Changing this to thin LTO increases the uncompressed binary size by 1.59
>>>>> MiB (+11%) (compressed +192KiB/+4.6%) but save us ~160s (-40%) of (wall)
>>>>> build time during a 'make deb'.
>>>> but what are the effects on runtime performance? the same question also
>>>> applies to the next patch, a single codegen unit increases the amount of
>>>> optimizations the compiler can do..
>>> FWIW, https://docs.wasmtime.dev/examples-minimal.html states:
>>>
>>> """
>>> Note that with LTO using a single codegen unit may only have marginal benefit.
>>> If not using LTO, however, a single codegen unit will likely provide benefit over the default 16 codegen units.
>>> """
>>>
>>> If that (still) holds, we currently do the worst of both worlds compile
>>> time wise while not really profiting from this. I'd probably try dropping
>>> overriding codegen units first (we do not lower that on performance other
>>> (non-wasm) critical code either, e.g. PBS.
>> Most perf related documentation seems to say codegen-units=1 and LTO=fat
>> are the way to go if you want to optimize for performance, though
>> whether that is true for wasm I don't know (the documentation there is
>> quite messy/outdated).
>>
>> AFAIK, it's how projects optimizing for performance build their release
>> binaries (i.e., firefox and rustc/cargo upstream both ship their
>> binaries built that way - they also tack on profile based optimizations
>> for even more gains). Would be interesting to test whether for PBS we'd
>> see benefits doing that as well?
>>
> The drawback is that PGO would make our builds non-reproducible.

yeah, I meant just codegen-units=1 and lto=fat here. PGO doesn't in
general make builds non-reproducible - but the profiles themselves are
(usually), which means they need to be generated separate from the
build, and tracked/checked-in. that's also the reason distros usually do
not enable PGO.

there have been some recent experiments with cargo upstream:

https://rust-lang.zulipchat.com/#narrow/channel/246057-t-cargo/topic/Optimizing.20Cargo.20with.20PGO/with/608544658

but for PBS in particular, finding a good benchmark/profiling run will
not be easy, since everything is so heavily I/O bound..