Replies

• 

  Guillaume GaullierGuillawme@fediscience.org

  Jun 26, 2026, 12:31 PM

  @civodul @zimoun Speaking of a faster 'guix pull', I recently saw these messages [1] (linking the last one, might need to rewind the thread) about having multiple smaller channels over one large main channel. I wondered if that could help making 'guix pull' faster?

  Do I understand correctly that 'guix pull' re-compiles all package definitions? If so, an ever growing main channel means 'guix pull' will take longer and longer as more package definitions are added to the channel.
  Is it where 'guix pull' spends most of its run time? If so, would it speed up 'guix pull' to only have "the essentials" (difficult to define, I know...) in the main channel? and everything else in thematic optional channels that would also be kept small (for example desktop environments, apps sorted by categories, etc.).

  Asking mostly out of curiosity. I know improving this takes a lot of effort. But yes if 'guix pull' can be made faster or lighter on CPU, it will make a noticeable difference in user experience.

  1: https://lists.gnu.org/archive/html/guix-devel/2026-05/msg00217.html

  💬 0🔄 0⭐ 3
• 

  Simon Tournierzimoun@sciences.re

  Jun 26, 2026, 3:20 PM

  @Guillawme Well, the “story” is “complicated”. 😁

  For some references, please give a look to this (point c):

  https://yhetil.org/guix/87let6roxo.fsf@jpoiret.xyz

  Or this:

  https://yhetil.org/guix/87wmxe3vsa.fsf@jpoiret.xyz
  https://yhetil.org/guix/87il8ddqkl.fsf@gnu.org

  @civodul

  💬 0🔄 0⭐ 2
• 

  Ludovic Courtèscivodul@toot.aquilenet.fr

  Jun 26, 2026, 8:03 PM

  @zimoun @Guillawme Also, the initial ‘guix pull’ (when you’ve never run ‘guix pull’ before) is extremely slow (~15m), but that is dominated by Git cloning.

  @shepherd has been looking into it lately, it’s become ~20% “less slow” a few days ago, and there are prospects of reducing it noticeably.

  💬 0🔄 0⭐ 0