Hi, Ricardo Wurmus <rek...@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’.
