[Top][All Lists]

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

Re: Speeding up “guix pull”: splitting modules

From: Christopher Baines
Subject: Re: Speeding up “guix pull”: splitting modules
Date: Thu, 16 Jan 2020 21:24:12 +0000
User-agent: mu4e 1.2.0; emacs 26.3

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 ":

Attachment: signature.asc
Description: PGP signature

reply via email to

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