From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from gate001.proxmox.com (gate001.proxmox.com [45.144.208.40]) by lore.proxmox.com (Postfix) with ESMTPS id 4BFDE1FF146 for ; Tue, 07 Jul 2026 16:51:56 +0200 (CEST) Received: from gate001.proxmox.com (localhost.localdomain [127.0.0.1]) by gate001.proxmox.com (Proxmox) with ESMTP id DE73D21436; Tue, 07 Jul 2026 16:51:55 +0200 (CEST) Date: Tue, 07 Jul 2026 16:51:48 +0200 From: Fabian =?iso-8859-1?q?Gr=FCnbichler?= Subject: Re: [PATCH datacenter-manager 2/3] ui: d/rules: use thin instead of fat LTO To: Dominik Csapak , pdm-devel@lists.proxmox.com References: <20260706114822.2751086-1-d.csapak@proxmox.com> <20260706114822.2751086-3-d.csapak@proxmox.com> <1783433095.x62omid41h.astroid@yuna.none> <9afa3e56-d06b-4cfc-acf5-580a04c7ca81@proxmox.com> In-Reply-To: <9afa3e56-d06b-4cfc-acf5-580a04c7ca81@proxmox.com> MIME-Version: 1.0 User-Agent: astroid/0.17.0 (https://github.com/astroidmail/astroid) Message-Id: <1783435812.ac5ljexier.astroid@yuna.none> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Bm-Milter-Handled: 55990f41-d878-4baa-be0a-ee34c49e34d2 X-Bm-Transport-Timestamp: 1783435904592 X-SPAM-LEVEL: Spam detection results: 0 AWL 0.100 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: UNIRKIKFM43IHLWC5KBVRWKT3LEFYEGW X-Message-ID-Hash: UNIRKIKFM43IHLWC5KBVRWKT3LEFYEGW X-MailFrom: f.gruenbichler@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: On July 7, 2026 4:10 pm, Dominik Csapak wrote: >=20 >=20 > On 7/7/26 4:05 PM, Fabian Gr=C3=BCnbichler 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.5= 9 >>> MiB (+11%) (compressed +192KiB/+4.6%) but save us ~160s (-40%) of (wall= ) >>> build time during a 'make deb'. >>=20 >> 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.. >=20 >=20 > 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..