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 6B21615800A for ; Mon, 31 Jul 2023 09:32:55 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 36516E0C4F; Mon, 31 Jul 2023 09:32:53 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [IPv6:2001:470:ea4a:1:5054:ff:fec7:86e4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id F297DE0B5D for ; Mon, 31 Jul 2023 09:32:52 +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> User-agent: mu4e 1.10.4; emacs 30.0.50 From: Sam James To: gentoo-dev@lists.gentoo.org Cc: =?utf-8?B?TWljaGHFgiBHw7Nybnk=?= Subject: Re: [gentoo-dev] [PATCH 1/7] eclass/nuget.eclass: introduce new eclass Date: Mon, 31 Jul 2023 10:32:20 +0100 Organization: Gentoo In-reply-to: <7bde7481-7fdd-ca86-3608-3eb704039dd2@gentoo.org> Message-ID: <87o7jsctof.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: 7ee61ec3-debc-4a33-9131-c52ab3cbaf0d X-Archives-Hash: 043a9b726425d8edd24238e19a43ff5e Florian Schmaus writes: > [[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 slightly >>> 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 and I already raised the point last week as well.