From: "Ludovic Courtès" <ludo@gnu.org>
To: Ricardo Wurmus <rekado@elephly.net>
Cc: guix-devel@gnu.org, pkill9 <pkill9@runbox.com>
Subject: Re: guix environment --profile with --ad-hoc
Date: Mon, 15 Mar 2021 17:23:03 +0100 [thread overview]
Message-ID: <87pn00fkt4.fsf@gnu.org> (raw)
In-Reply-To: <87h7lgpqda.fsf@elephly.net> (Ricardo Wurmus's message of "Fri, 12 Mar 2021 12:23:45 +0100")
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’.
next prev parent reply other threads:[~2021-03-15 16:23 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-03-09 2:05 guix environment --profile with --ad-hoc pkill9
2021-03-09 7:25 ` Lars-Dominik Braun
2021-03-09 8:20 ` Pierre Neidhardt
2021-03-09 8:28 ` Lars-Dominik Braun
2021-03-11 20:04 ` Pierre Neidhardt
2021-03-12 9:47 ` zimoun
2021-03-12 9:59 ` Pierre Neidhardt
2021-03-12 11:23 ` Ricardo Wurmus
2021-03-12 11:26 ` Pierre Neidhardt
2021-03-12 13:12 ` zimoun
2021-03-15 16:23 ` Ludovic Courtès [this message]
2021-03-12 10:42 ` Lars-Dominik Braun
2021-03-12 10:51 ` Pierre Neidhardt
2021-03-12 15:44 ` Pierre Neidhardt
2021-03-13 7:59 ` Lars-Dominik Braun
2021-03-13 8:55 ` Pierre Neidhardt
2021-03-15 9:25 ` zimoun
2021-03-10 10:04 ` pkill9
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87pn00fkt4.fsf@gnu.org \
--to=ludo@gnu.org \
--cc=guix-devel@gnu.org \
--cc=pkill9@runbox.com \
--cc=rekado@elephly.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/guix.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.