Hello again, De Simon Tournier le 12/10/2023 à 19:02: > On Thu, 12 Oct 2023 at 15:51, Emmanuel Beffara <m...@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
