guix-devel
[Top][All Lists]
Advanced

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

Guix pull speed


From: Josselin Poiret
Subject: Guix pull speed
Date: Tue, 29 Aug 2023 13:58:13 +0200

Hi everyone,

After looking a bit more into guix pull speed, or to be more precise the
"Computing Guix derivation..." step, which is not substitutable.  I've
come to the conclusion that the thing that takes the majority of the
time is loading the files that define the packages that the new Guix
needs to build itself.  These files are not compiled yet, and worse,
loading just (gnu packages guile) ends up loading 361 other package
files.  You can generate a package graph in GraphML with `guix graph -t
module -b graphml guile`, and use e.g. networkx to analyze it.

You can compare with a compiled check-out of guix by just running the
following in a `guix repl`:
--8<---------------cut here---------------start------------->8---
(use-modules (guix self) (guix monad-repl))
,run-in-store (guix-derivation (getcwd) "0.0-git" #:pull-version 1)
--8<---------------cut here---------------end--------------->8---
which takes at most 5 seconds on my laptop.

One idea I had was to move all the packages that are looked up in (guix
self) to their own little bubble, to avoid having to load extra stuff.
However, this is not currently possible because some of them do have
non-trivial dependency graphs.  I've identified these problematic
inputs: guile-avahi guile-ssh guile-git guile-gnutls guix-daemon (it
pulls in all other dependencies itself) po4a graphviz

What could be done about this?  Another solution would be to somehow
build Guix without any of the dependencies and then add them in later,
similar to what is done with build-aux/build-self.scm to be able to load
(guix self) in the first place.  That seems quite complex though.

Best,
-- 
Josselin Poiret

Attachment: signature.asc
Description: PGP signature


reply via email to

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