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

[Ludovic Courtès]

Hi,

Ricardo Wurmus <rekado@elephly.net> 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)
guix-command):

--8<---------------cut here---------------start------------->8---
$ ./pre-inst-env strace -c guix build hello -d
/gnu/store/cl250cyzml3sk521y0n6940cr60r481x-hello-2.10.drv
% 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
/gnu/store/cl250cyzml3sk521y0n6940cr60r481x-hello-2.10.drv
% 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
isn’t.)

> 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
impact.

Ludo’.