Slow guix pull

[Simon Tournier <zimon.toutoune@gmail.com>]

Hi,

On Sat, 24 Jun 2023 at 09:33, Vagrant Cascadian <vagrant@debian.org> wrote:

> So, presuming substitutes are available, the main slowness with guix
> seems to be guix pull?

I agree (and for the record, I would add in addition “guix search” too,
another story :-)).


Well, from my understanding about “guix pull”, the first bottleneck is
about “Computing Guix derivation for ...” from build-aux/build-self.scm.

Maybe I misread something and for sure I am probably missing some
details.  On my desktop machine, that part takes 84 seconds, roughly.
From my understanding, it’s because of this procedure,

--8<---------------cut here---------------start------------->8---
(define (proxy input output)
  "Dump the contents of INPUT to OUTPUT until EOF is reached on INPUT.
Display a spinner when nothing happens."
  (define spin
    (circular-list "-" "\\" "|" "/" "-" "\\" "|" "/"))

  (setvbuf input 'block 16384)
  (let loop ((spin spin))
    (match (select (list input) '() '() 1)
      ((() () ())
       (when (isatty? (current-error-port))
         (display (string-append "\b" (car spin))
                  (current-error-port))
         (force-output (current-error-port)))
       (loop (cdr spin)))
      (((_) () ())
       ;; Read from INPUT as much as can be read without blocking.
       (let ((bv (get-bytevector-some input)))
         (unless (eof-object? bv)
           (put-bytevector output bv)
           (loop spin)))))))
--8<---------------cut here---------------end--------------->8---

that is called by,

        ;; Wait for a connection on SOCK and proxy build output so it can be
        ;; processed according to the settings currently in effect (build
        ;; traces, verbosity level, and so on).
        (match (accept sock)
          ((port . _)
           (close-port sock)
           (delete-file node)
           (proxy port (current-build-output-port))))

And that dump is currently on strong annoyance, IMHO.  Because most of
the other derivations can be substituted but this part cannot, again
from my poor understanding.

Note that this part can be very painful.  For example, on my laptop from
2016, it takes ~180 seconds.  Well, 3 minutes for “dumping content”…
that’s a piece of content! :-)

Well, I do not know exactly which kind of content is living at ’port’
and then if ’(current-build-output-port)’ needs all this content.
Therefore, I do not know if something could be trimmed… but I guess
something could be improved here.


Cheers,
simon