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

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

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?