[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: guix environment --profile with --ad-hoc

From: Ludovic Courtès
Subject: Re: guix environment --profile with --ad-hoc
Date: Mon, 15 Mar 2021 17:23:03 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/27.1 (gnu/linux)


Ricardo Wurmus <> skribis:

> strace reveals more.  For example, some time is lost searching libraries
> and other files.  (At least the excessive library searches should
> already have been mitigated by changes on the core-updates branch.)
> This includes reading .go files, .scm files, reading TLS certs for
> guile-gnutls, etc.

I think you’re stracing via ./pre-inst-env.  ‘guix’ from ‘guix pull’
stats less thanks to the optimizations in (@@ (guix self)

--8<---------------cut here---------------start------------->8---
$ ./pre-inst-env strace -c guix build hello -d
% time     seconds  usecs/call     calls    errors syscall
------ ----------- ----------- --------- --------- ------------------
 54.03    0.009214           1      6542      4863 stat
 12.46    0.002124           2      1023           mmap
  9.30    0.001585           1      1535       626 openat


------ ----------- ----------- --------- --------- ------------------
100.00    0.017052           1     14180      5528 total
$ strace -c guix build hello -d
% time     seconds  usecs/call     calls    errors syscall
------ ----------- ----------- --------- --------- ------------------
 28.77    0.002299           1      1282       625 openat
 20.77    0.001660           1      1519       325 stat


------ ----------- ----------- --------- --------- ------------------
100.00    0.007991           0      8143       983 total
--8<---------------cut here---------------end--------------->8---

(The former is sensitive to the length of GUILE_LOAD_PATH, the latter

> I’m guessing that we could avoid some of that searching (and thus
> condense a whole lot of stat calls) by constraining things a little
> ahead of time.  We know the location of Guile modules in advance, so
> perhaps we can come up with a way to avoid having to go on
> GUILE_LOAD_PATH and GUILE_LOAD_COMPILED_PATH for everything, e.g. by
> recording GUIX_ROOT and using that.

Yes, that’s what the “package cache” built by ‘guix pull’ does.
Essentially, it makes it so that:

  guix build hello

is equivalent to:

  guix build -e '(@ (gnu packages base) hello)'

> But this is still all rather benign.  The real slow-down is due to
> talking to the daemon.  I’m not sure I understand all the strace output,
> but it looks like we read file names from the daemon socket and then
> write the contents of the builders and derivations for these files back
> to the daemon socket.
> It’s not clear to me if Guix computes these builders and derivations
> from scratch and then sends them over the socket, or if it reads them
> from files and sends them over.  But it does seem like perhaps we could
> avoid some of the work, or at least some of the socket communication
> when the daemon could read existing files directly.

All the derivations and builders are computed from scratch, so caches
(notably the cache that maps packages to derivations) have a huge


reply via email to

[Prev in Thread] Current Thread [Next in Thread]