guix-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: substitute derivation: also substitute grafts?


From: Csepp
Subject: Re: substitute derivation: also substitute grafts?
Date: Thu, 15 Sep 2022 19:43:01 +0200

Maxime Devos <maximedevos@telenet.be> writes:

> [[PGP Signed Part:Undecided]]
>
>
> On 15-09-2022 16:46, Csepp wrote:
>> Ricardo Wurmus <rekado@elephly.net> writes:
>> 
>>> [...]
>>> Did I say *all items*? Well, … grafts are not included, because
>>> graft
>>> derivations are marked as not substitutable.
>>>
>>> Can we change that conditionally? I would really like to avoid
>>> having
>>> to build grafts on B when they have already been built on A.
>> I would love this too, because IO can be incredibly slow on HDDs and
>> large packages.  My netbook would be thankful.
>>
>
> There are some some opportunities for optimizations in the grafting
> code before substituting more -- for example, to avoid seek times, it
> would be possible to rewrite multiple files concurrently (maybe using
> 'par-for-each' to process each file in a directory in parallel).
>
> This is already done in (guix build grafts), except that:
>
>  * 'find-files' itself is not parallelised, even though parallelising it
>     could potentially reduce the time spent seeking (*)
>  * it uses (parallel-job-count), which is (IIUC) 1 by default because
>    --cores=1 by default.  As grafts are more IO intensive than CPU
>    intensive, maybe it would be reasonable to impose a _minimum_ amount
>    of parallelism, I don't, know, 2 or 4 or so?
>
> (I'm assuming the main problem here is seek times.)
>
> Also combinable with the proposal of having substitutes for grafts.
>
> Greetings,
> Maxime.
>
> (*) IIUC, the time for N parallel seeks should, in theory, ≃ 1 seek,
> for small values of N, because of elevator algorithms.
>
> [2. OpenPGP public key --- application/pgp-keys; 
> OpenPGP_0x49E3EE22191725EE.asc]...
>
> [[End of PGP Signed Part]]

Could we store the offsets of references somewhere at build time?



reply via email to

[Prev in Thread] Current Thread [Next in Thread]