From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by finch.gentoo.org (Postfix) with ESMTPS id B0FCF15800A for ; Mon, 31 Jul 2023 13:53:31 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 212BBE0CA5; Mon, 31 Jul 2023 13:53:28 +0000 (UTC) Received: from smtp.gentoo.org (woodpecker.gentoo.org [140.211.166.183]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id D9BFCE0C9D for ; Mon, 31 Jul 2023 13:53:27 +0000 (UTC) Message-ID: <47d02e5594b3c2be86e2a89966edab3dffae572f.camel@gentoo.org> Subject: Re: [gentoo-dev] [PATCH 1/7] eclass/nuget.eclass: introduce new eclass From: =?UTF-8?Q?Micha=C5=82_G=C3=B3rny?= To: gentoo-dev@lists.gentoo.org Date: Mon, 31 Jul 2023 15:53:23 +0200 In-Reply-To: References: <20230730142647.872-1-xgqt@gentoo.org> <4766db0bfe4ba2b55d74034f83608b8461145808.camel@gentoo.org> <3293c666-6d3c-8aaf-37f7-35020bd3decf@gentoo.org> <7bde7481-7fdd-ca86-3608-3eb704039dd2@gentoo.org> <87o7jsctof.fsf@gentoo.org> Organization: Gentoo Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.48.4 Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org X-Auto-Response-Suppress: DR, RN, NRN, OOF, AutoReply MIME-Version: 1.0 X-Archives-Salt: eadc92c7-7140-4af6-95aa-5099c3e46f3d X-Archives-Hash: aacb1623628472afa54c02c4d14a5508 On Mon, 2023-07-31 at 12:49 +0200, Florian Schmaus wrote: > On 31/07/2023 11.32, Sam James wrote: > >=20 > > Florian Schmaus writes: > >=20 > > > [[PGP Signed Part:Undecided]] > > > On 31/07/2023 07.02, Micha=C5=82 G=C3=B3rny wrote: > > > > On Sun, 2023-07-30 at 22:19 +0200, Florian Schmaus wrote: > > > > > Which problem are we solving by moving away from this towards a s= lightly > > > > > more verbose construct? > > > > The problem was that cargo.eclass ebuilds were taking significant > > > > time > > > > during cache regeneration and slowing down tools noticeably. No fa= ncy > > > > loops required, contrary to your great theory. > > >=20 > > > Removing the $()/fork from go-modules.eclass reduced the source time > > > of a package from 2400 milliseconds to 236 milliseconds. > > >=20 > > > Changing, for example net-p2p/arti-1.1.6, to use _cargo_set_crate_uri= s > > > reduces the source time from 44 milliseconds to 24 milliseconds. > > >=20 > > > That is a win in relative reduction, but absolute its just 20 > > > milliseconds. Cache regeneration is an embarrassingly parallel > > > problem. Therefore such a reduction should not matter much, assuming > > > you have some parallelism on the hardware level. > >=20 > > Consistency matters >=20 > Sure, I would be in favor of consistently using $(foo_uris). >=20 > Especially since the performance gains of the variable-setting approach= =20 > are even lower than I first assumed. The cargo.eclass runs the function= =20 > that computes CARGO_CRATE_URIS now twice, which adds significantly more= =20 > overhead than the fork of $(foo_uris). See my patch to the ML. >=20 So, to summarize, your point is that after you've ignored the original thread and we've actually started switching stuff to ${xxx}, we should reopen the discussion and start moving everything back to $(xxx), even though you've proven yourself that it's less optimal ("but only a little!") and because... you prefer it? Yes, that certainly makes sense. It's surely a great way to run a distro is to undo optimizations 6 weeks later because you liked the old variant better. --=20 Best regards, Micha=C5=82 G=C3=B3rny