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).

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?

- Flow