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 8449C15800A for ; Mon, 31 Jul 2023 11:40:15 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id ED093E0CA1; Mon, 31 Jul 2023 11:40:11 +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 512ECE0C88 for ; Mon, 31 Jul 2023 11:40:11 +0000 (UTC) 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> User-agent: mu4e 1.10.4; emacs 30.0.50 From: Sam James To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] [PATCH 1/7] eclass/nuget.eclass: introduce new eclass Date: Mon, 31 Jul 2023 12:39:30 +0100 Organization: Gentoo In-reply-to: Message-ID: <87edkocns8.fsf@gentoo.org> 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 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Archives-Salt: 4a4f8e09-3d10-4085-a544-522c47045e27 X-Archives-Hash: a8dcc37fb64bd33e48fb754d7150c280 Florian Schmaus writes: > [[PGP Signed Part:Undecided]] > On 31/07/2023 11.32, Sam James wrote: >> 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 sligh= tly >>>>> more verbose construct? >>>> The problem was that cargo.eclass ebuilds were taking significant >>>> time >>>> during cache regeneration and slowing down tools noticeably. No fancy >>>> loops required, contrary to your great theory. >>> >>> Removing the $()/fork from go-modules.eclass reduced the source time >>> of a package from 2400 milliseconds to 236 milliseconds. >>> >>> Changing, for example net-p2p/arti-1.1.6, to use _cargo_set_crate_uris >>> reduces the source time from 44 milliseconds to 24 milliseconds. >>> >>> 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. >> Consistency matters > > Sure, I would be in favor of consistently using $(foo_uris). Too late for that. Please don't reopen the cargo.eclass issue unnecessarily. > > Especially since the performance gains of the variable-setting > approach are even lower than I first assumed. The cargo.eclass runs > the function that computes CARGO_CRATE_URIS now twice, which adds > significantly more overhead than the fork of $(foo_uris). See my patch > to the ML. > >> and I already raised the point last week as well. > > Here on the mailing list, or somewhere else? > Here on the mailing list.