Re: Speeding up “guix pull”: splitting modules

[Christopher Baines]

Ludovic Courtès <address@hidden> writes:

> BTW, there’s also the “Compute Guix derivation” phase that could be sped
> up, and that’s mostly independent of Guile.
>
> Things that could help include: “recursive Nix”¹ (the Guix derivation
> would itself be the result of a derivation, thus subject to
> substitutes), or something equivalent without special daemon support
> where we’d simply embed (guix derivations) & co. to compute the
> derivation in memory.
>
> Another less elegant option would be to resort to a service (Data
> Service or Cuirass) that would map a Guix commit to its .drv, and then
> fetch that .drv from substitute servers and build it.

I haven't got around to storing the derivations for `guix pull` in the
Guix Data Service, but it does provide substitutes for derivations now,
so support for this is only one step away now.

> Finally, we could/should also profile that phase and see what can be
> done.
>
> Lastly :-), it would be great to profile this phase over time to see how
> it evolves.  (Does the Guix Data Service already stores timings for such
> things?)

There are timings output in the logs for jobs ([1] for example), it's
not really feasible to compare that across different revisions.

I do want to improve the process of loading data in to the Guix Data
Service though, and that might involve storing this data in a more
structured way, so that it can be analysed more easily.


1: look for ", took ": http://data.guix.gnu.org/job/10722

signature.asc
Description: PGP signature