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

[Dominik Csapak <d.csapak@proxmox.com>]

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