Re: [gentoo-dev] [PATCH 1/7] eclass/nuget.eclass: introduce new eclass

[Sam James <sam@gentoo.org>]

Florian Schmaus <flow@gentoo.org> writes:

> [[PGP Signed Part:Undecided]]
> On 31/07/2023 11.32, Sam James wrote:
>> Florian Schmaus <flow@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.