From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from gate001.proxmox.com (gate001.proxmox.com [IPv6:2a0f:8001:1:32::40]) by lore.proxmox.com (Postfix) with ESMTPS id 51A201FF13A for ; Wed, 08 Jul 2026 12:28:44 +0200 (CEST) Received: from gate001.proxmox.com (localhost.localdomain [127.0.0.1]) by gate001.proxmox.com (Proxmox) with ESMTP id 6280221448; Wed, 08 Jul 2026 12:28:42 +0200 (CEST) Message-ID: <9650d59b-ba22-4636-8103-92894fe306c6@proxmox.com> Date: Wed, 8 Jul 2026 12:27:57 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Beta Subject: Re: [PATCH datacenter-manager 0/3] ui: reduce compilation time for relase builds From: Dominik Csapak To: pdm-devel@lists.proxmox.com References: <20260706114822.2751086-1-d.csapak@proxmox.com> Content-Language: en-US In-Reply-To: <20260706114822.2751086-1-d.csapak@proxmox.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Bm-Milter-Handled: 55990f41-d878-4baa-be0a-ee34c49e34d2 X-Bm-Transport-Timestamp: 1783506477522 X-SPAM-LEVEL: Spam detection results: 0 AWL 0.058 Adjusted score from AWL reputation of From: address DMARC_MISSING 0.1 Missing DMARC policy KAM_DMARC_STATUS 0.01 Test Rule for DKIM or SPF Failure with Strict Alignment (newer systems) SPF_HELO_NONE 0.001 SPF: HELO does not publish an SPF Record SPF_PASS -0.001 SPF: sender matches SPF record Message-ID-Hash: 4ZBKJNCDYGFCGJKIYJV3GLB2JPRG6PB2 X-Message-ID-Hash: 4ZBKJNCDYGFCGJKIYJV3GLB2JPRG6PB2 X-MailFrom: d.csapak@proxmox.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; loop; banned-address; emergency; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header X-Mailman-Version: 3.3.10 Precedence: list List-Id: Proxmox Datacenter Manager development discussion List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: 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 via serde * "json serialize": converts the Vec 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