Florian Schmaus <f...@gentoo.org> writes:
> [[PGP Signed Part:Undecided]] > On 31/07/2023 11.32, Sam James wrote: >> Florian Schmaus <f...@gentoo.org> writes: >> >>> [[PGP Signed Part:Undecided]] >>> On 31/07/2023 07.02, Michał Górny 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 > > 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.
