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.

If switching to the variable-setting approach for something like 
cargo_crate_uris only motivated by reducing the cache regeneration a 
bit, then it is IMO borderline if its justified.

- Flow