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
OpenPGP_0x8CAC2A9678548E35.asc
Description: OpenPGP public key
OpenPGP_signature
Description: OpenPGP digital signature
