[PATCH datacenter-manager 0/3] ui: reduce compilation time for relase builds

[PATCH datacenter-manager 0/3] ui: reduce compilation time for relase builds

[Dominik Csapak]

By sacrificing some space savings:

All three patches save us some time during 'make build' (for per patch
improvements see the individual patches), but 2/3 and 3/3 sacrifice some
space savings.

Note that the numbers in the patches are measured against the baseline
and all three patches together seem to have an even larger effect:

They save us ~250s (-65%) but the file only gets bigger by 2.3 MiB
(+16%) uncompressed, and 420Kib (+10%) compressed.

Not sure if we want to trade binary size by compile time in this way,
but at least the first patch should be a no-brainer since it does not
change the binary size at all.

Aside from these flags, there aren't that many knobs we have in the code
itself to reduce compile time, aside from removing dependencies and
keeping the whole project smaller.

Maybe splitting the pve-api-types into smaller chunks could help (we
only use a small fraction of it in the ui) or replacing some bigger
crates with smaller ones just for the gui (or replacing with browser
native code where possible, maybe base64 and such things?)

Dominik Csapak (3):
  ui: d/rules: don't generate debuginfo for the UI
  ui: d/rules: use thin instead of fat LTO
  ui: d/rules: don't limit compilation to 1 codgen-unit

 ui/debian/rules | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

-- 
2.47.3

[PATCH datacenter-manager 1/3] ui: d/rules: don't generate debuginfo for the UI

[Dominik Csapak]

It's built to wasm, which does not have dbgsym so generating these is
just unnecessary waste. Omitting this saves us ~20s per 'make deb' and
should produce identical binaries since wasm-bindgen strips the debug
info anyway.

Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
---
 ui/debian/rules | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/ui/debian/rules b/ui/debian/rules
index 8a81f126..b3b3b078 100755
--- a/ui/debian/rules
+++ b/ui/debian/rules
@@ -27,12 +27,13 @@ ifneq ($(DEB_DISTRIBUTION),UNRELEASED)
 endif
 
 	$(CARGO) prepare-debian $(CURDIR)/debian/cargo_registry --link-from-system
+	sed -e 's/^debug = true$$/debug = false/g' debian/cargo_home/config.toml
 	echo "\nlto=\"fat\"" >> debian/cargo_home/config.toml
 	echo "\nopt-level=\"s\"" >> debian/cargo_home/config.toml
 	echo "\ncodegen-units=1" >> debian/cargo_home/config.toml
 	# patch cargo_home config to use lld with wasm, otherwise the build fails
 	echo "\n[target.wasm32-unknown-unknown]" >> debian/cargo_home/config.toml
-	cat debian/cargo_home/config.toml | sed "s/linker=[^']\+/linker=rust-lld/" | grep "^rustflags = " >> debian/cargo_home/config.toml
+	cat debian/cargo_home/config.toml | sed -e "s/linker=[^']\+/linker=rust-lld/" -e "s/'-C', 'debuginfo=[^']*', //g" | grep "^rustflags = " >> debian/cargo_home/config.toml
 	dh_auto_configure
 
 override_dh_strip:
-- 
2.47.3

Re: [PATCH datacenter-manager 1/3] ui: d/rules: don't generate debuginfo for the UI

[Fabian Grünbichler]

On July 6, 2026 1:44 pm, Dominik Csapak wrote:
> It's built to wasm, which does not have dbgsym so generating these is
> just unnecessary waste. Omitting this saves us ~20s per 'make deb' and
> should produce identical binaries since wasm-bindgen strips the debug
> info anyway.

it only strips it because we tell it to, right? at some point, we might
want to reconsider and ship a debug variant (and allow loading it via
the API service) to make debugging things easier for users? but I guess
at the moment the debugging story is not too great in general..

> Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
> ---
>  ui/debian/rules | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/ui/debian/rules b/ui/debian/rules
> index 8a81f126..b3b3b078 100755
> --- a/ui/debian/rules
> +++ b/ui/debian/rules
> @@ -27,12 +27,13 @@ ifneq ($(DEB_DISTRIBUTION),UNRELEASED)
>  endif
>  
>  	$(CARGO) prepare-debian $(CURDIR)/debian/cargo_registry --link-from-system
> +	sed -e 's/^debug = true$$/debug = false/g' debian/cargo_home/config.toml
>  	echo "\nlto=\"fat\"" >> debian/cargo_home/config.toml
>  	echo "\nopt-level=\"s\"" >> debian/cargo_home/config.toml
>  	echo "\ncodegen-units=1" >> debian/cargo_home/config.toml
>  	# patch cargo_home config to use lld with wasm, otherwise the build fails
>  	echo "\n[target.wasm32-unknown-unknown]" >> debian/cargo_home/config.toml
> -	cat debian/cargo_home/config.toml | sed "s/linker=[^']\+/linker=rust-lld/" | grep "^rustflags = " >> debian/cargo_home/config.toml
> +	cat debian/cargo_home/config.toml | sed -e "s/linker=[^']\+/linker=rust-lld/" -e "s/'-C', 'debuginfo=[^']*', //g" | grep "^rustflags = " >> debian/cargo_home/config.toml

I think this is missing the `strip` part of rustflags here? though I
haven't tested whether it's more effecient to let rustc strip than to
let wasm-bindgen do it later..

>  	dh_auto_configure
>  
>  override_dh_strip:
> -- 
> 2.47.3
> 
> 
> 
> 
> 
> 

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

[Dominik Csapak]

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

Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
---
 ui/debian/rules | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/ui/debian/rules b/ui/debian/rules
index b3b3b078..8ffa868a 100755
--- a/ui/debian/rules
+++ b/ui/debian/rules
@@ -28,7 +28,7 @@ endif
 
 	$(CARGO) prepare-debian $(CURDIR)/debian/cargo_registry --link-from-system
 	sed -e 's/^debug = true$$/debug = false/g' debian/cargo_home/config.toml
-	echo "\nlto=\"fat\"" >> debian/cargo_home/config.toml
+	echo "\nlto=\"thin\"" >> debian/cargo_home/config.toml
 	echo "\nopt-level=\"s\"" >> debian/cargo_home/config.toml
 	echo "\ncodegen-units=1" >> debian/cargo_home/config.toml
 	# patch cargo_home config to use lld with wasm, otherwise the build fails
-- 
2.47.3

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

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

> Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
> ---
>  ui/debian/rules | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/ui/debian/rules b/ui/debian/rules
> index b3b3b078..8ffa868a 100755
> --- a/ui/debian/rules
> +++ b/ui/debian/rules
> @@ -28,7 +28,7 @@ endif
>  
>  	$(CARGO) prepare-debian $(CURDIR)/debian/cargo_registry --link-from-system
>  	sed -e 's/^debug = true$$/debug = false/g' debian/cargo_home/config.toml
> -	echo "\nlto=\"fat\"" >> debian/cargo_home/config.toml
> +	echo "\nlto=\"thin\"" >> debian/cargo_home/config.toml
>  	echo "\nopt-level=\"s\"" >> debian/cargo_home/config.toml
>  	echo "\ncodegen-units=1" >> debian/cargo_home/config.toml
>  	# patch cargo_home config to use lld with wasm, otherwise the build fails
> -- 
> 2.47.3
> 
> 
> 
> 
> 
> 

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

[Dominik Csapak]

On 7/7/26 4:05 PM, Fabian Grünbichler wrote:
> 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..


true, i didn't measure that. I'll see that i can come up with some
sensible gui benchmark to measure this and I'll report back
with the numbers..

> 
>> Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
>> ---
>>   ui/debian/rules | 2 +-
>>   1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/ui/debian/rules b/ui/debian/rules
>> index b3b3b078..8ffa868a 100755
>> --- a/ui/debian/rules
>> +++ b/ui/debian/rules
>> @@ -28,7 +28,7 @@ endif
>>   
>>   	$(CARGO) prepare-debian $(CURDIR)/debian/cargo_registry --link-from-system
>>   	sed -e 's/^debug = true$$/debug = false/g' debian/cargo_home/config.toml
>> -	echo "\nlto=\"fat\"" >> debian/cargo_home/config.toml
>> +	echo "\nlto=\"thin\"" >> debian/cargo_home/config.toml
>>   	echo "\nopt-level=\"s\"" >> debian/cargo_home/config.toml
>>   	echo "\ncodegen-units=1" >> debian/cargo_home/config.toml
>>   	# patch cargo_home config to use lld with wasm, otherwise the build fails
>> -- 
>> 2.47.3
>>
>>
>>
>>
>>
>>

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

[Fabian Grünbichler]

On July 7, 2026 4:10 pm, Dominik Csapak wrote:
> 
> 
> On 7/7/26 4:05 PM, Fabian Grünbichler wrote:
>> 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..
> 
> 
> true, i didn't measure that. I'll see that i can come up with some
> sensible gui benchmark to measure this and I'll report back
> with the numbers..

and for completeness' sake - one way to solve this would be to split the
"release" build from a "fast" build (by putting one of them behind a
build profile). then the fast build could use thin LTO and multiple
codegen units, and the regular release build could still be optimized
for size and runtime speed (while taking longer to complete).

the "fast" build would then mainly be a final gate before submitting
patches, since most development will happen via trunk anyway..

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

[Thomas Lamprecht]

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.

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

[Fabian Grünbichler]

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?

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

[Robert Obkircher]

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

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

[Fabian Grünbichler]

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

[PATCH datacenter-manager 3/3] ui: d/rules: don't limit compilation to 1 codgen-unit

[Dominik Csapak]

This makes the compilation of big crates (pdm-ui/proxmox-yew-comp/etc.)
much slower. By removing this, the compiled file grows by ~484 KiB (+3%)
(+156KiB/+3.7% compressed) but we save ~34s of compile time (-9%).

Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
---
 ui/debian/rules | 1 -
 1 file changed, 1 deletion(-)

diff --git a/ui/debian/rules b/ui/debian/rules
index 8ffa868a..a4d0fa0f 100755
--- a/ui/debian/rules
+++ b/ui/debian/rules
@@ -30,7 +30,6 @@ endif
 	sed -e 's/^debug = true$$/debug = false/g' debian/cargo_home/config.toml
 	echo "\nlto=\"thin\"" >> debian/cargo_home/config.toml
 	echo "\nopt-level=\"s\"" >> debian/cargo_home/config.toml
-	echo "\ncodegen-units=1" >> debian/cargo_home/config.toml
 	# patch cargo_home config to use lld with wasm, otherwise the build fails
 	echo "\n[target.wasm32-unknown-unknown]" >> debian/cargo_home/config.toml
 	cat debian/cargo_home/config.toml | sed -e "s/linker=[^']\+/linker=rust-lld/" -e "s/'-C', 'debuginfo=[^']*', //g" | grep "^rustflags = " >> debian/cargo_home/config.toml
-- 
2.47.3

Re: [PATCH datacenter-manager 0/3] ui: reduce compilation time for relase builds

[Dominik Csapak]

I did some runtime benchmarks now:

generates 20000 random pve guest resources (with a fixed seeded RNG so 
it's comparable)

included are 4 micro benchmarks:
* "json parse": parses a json string of the resourcess into a 
Vec<Resources> via serde
* "json serialize": converts the Vec<Resources>  into a string via serde
* "sort + filter": clones the list, and does 2 sort operations and
one filter operation on it.
* "vdom build": takes the first 5000 elements of the list and creates a 
row for every item and adds it to a column. in memory only, is not rendered

and one real world benchmark "dom render": renders the 5000 elements
into a (non-buffered) data table and changes the content and moves the
elements around.

configuration  "json parse"    "json serialize"  "sort + filter"  "vdom 
build"   "dom render"
current         21.1            15.8              5.6              14.0 
          567.9
thin-lto        22.1 (+4.7%)    16.4  (+3.8%)     5.5 (-1.8%)      14.6 
(+4.2%)   574.5 (+1.2%)
codegen-units   21.4 (+1.4%)    13.1 (-17.1%)     5.7 (+1.8%)      13.8 
(-1.4%)   575.8 (+1.4%)
all             22.8 (+8.0%)    16.4 (+3.8%)      5.6 (+0.0%)      15.2 
(+8.5%)   591.0 (+4.1%)
trunk-debug     155.3 (+636%)   120.4 (+662%)     16.2 (+189%)     88.8 
(+534%)   1210.6 (+113%)
trunk-release   19.6 (-7.1%)    9.3 (-41.1%)      5.5 (-1.8%)      13.6 
(-2.9%)   567.8 (-0.0%)
(did not test no-debug only as it does not change the binary)

at worst we sacrifice 8% on json parsing, but this is done only e.g.
every few seconds, and not constantly (and usually not on such big
datasets). The rendering takes also a 4% hit but we're talking here
multiple thousands of elements and the absolute change is just ~25ms.

for good measure i also threw in the trunk debug/release builds
which behave as expected (the release build does not optimize for size
so it's not surprising it's faster on runtime)

the LTO change does make up the largest part of the difference,
so we could opt to just do the codegen part which seems to not impact
the performance too much

let me know if i should do more benchmarks/tests