Hi Simon, Simon Tournier writes: > Hi Josselin, > > On Tue, 29 Aug 2023 at 13:58, Josselin Poiret wrote: > >> 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. > > Well, on my machine, the bigger bottleneck seems the procedure name > ’proxy’ which copies stuff around, IIUC. See [1]. Proxy is on the helper script side, it's just waiting for the actual build script to do its thing. >> 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. > > Hum, is this ’graphml’ something you have not submitted? Or am I > missing a point? Last time I played with “guix graph”, I wrote a small > script for bridging with networkx. See [2]. I've committed it pretty recently, and should work OOTB now. >> 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. > > Yeah, that’s fast. :-) > > For comparing, what would be the corresponding derivations that “guix > pull” is building? It's building the same! Just that building the derivation takes way longer because it has first to load a bunch of uncompiled guile files. Best, -- Josselin Poiret