Re: guix pull performance

[Emmanuel Beffara]

Hello again,

De Simon Tournier le 12/10/2023 à 19:02:
> On Thu, 12 Oct 2023 at 15:51, Emmanuel Beffara <manu@beffara.org> wrote:
> 
> > Thanks for the pointer. Now I think I understand the reason for this
> > behaviour: Guix has to compile the whole set of modules, including all 
> > package
> > definitions, and it is rather slow at that. So I guess I won't expect
> > significant improvement in the near future, but at least it's not an issue
> > with my particular installation!
> 
> If it is not already the case, you might be interested by:
> 
> https://guix.gnu.org/manual/devel/en/guix.html#Channels-with-Substitutes

I didn't answer to that at the time, but I do use channels with substitutes as
described in the documentation. I only have the default channel as desribed
there, plus a small custom channel in a local git repository where I put
definitions for custom packages and for third-party packages that I need
(which I intend to propose for integration in Guix itself eventually).
I actually use another channel with less libre kernels and firmwares, but I
disabled it for testing pull times (and it doesn't change things much).

Now, even if I didn't expect a significant improvement, I am still badly
surprised by the behaviour of Guix: one month ago, any `guix pull` took 10
minutes to complete, and these days it takes 40 minutes (the same command, on
the same machine in the same conditions). When running a second `guix pull`
while the channels are unchanged, it takes "only" 6 minutes of computation
before telling me that there is nothing to do.

How is it possible that things are four times slower over just one month ?
Did the package collection increase that much ?
Were there structural changes that caused a loss of efficiency ?

Or might there actually be someting wrong with my setup, and in this case how
could I diagnose it ?

Updating Guix is becoming painful, and if run times continue with their
exponential growth, it will become simply unusable.

-- 
Emmanuel