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

[Robert Obkircher <r.obkircher@proxmox.com>]

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.
>
>