Re: Combining Guix, direnv and Emacs for environment customisation

[Ludovic Courtès]

Hi Roel,

Roel Janssen <address@hidden> skribis:

> Ludovic Courtès writes:

[...]

>>> FWIW, on our NFS-mounted /gnu, the 'guix environment' command takes at
>>> least 20 seconds, but for any reasonably big environment it takes more
>>> than one minute.  The biggest bottleneck here is the disk latency.
>>> Could it be that 'guix environment' accesses many files?  If we could
>>> reduce that, it would speed things up (at least for us ;)).
>>
>> Interesting.   Does guix-daemon access /gnu over NFS too?
>
> Yes.

That is going to make builds verrrry slow.  I would suggest having
guix-daemon operate on the local /gnu (that’s what Ricardo did, IIRC).

>> We stat a lot mostly to access all the Guix modules.  Are they on NFS
>> too?
>
> Yes.

OK.

> Here's my output:
>
> address@hidden ~]$ strace -c guix environment --ad-hoc coreutils --pure -- 
> true
> % time     seconds  usecs/call     calls    errors syscall
> ------ ----------- ----------- --------- --------- ----------------
>  41.79    0.038363          22      1782       188 open
>  14.71    0.013500           3      4769      1747 stat
>  13.19    0.012106           2      8033           read
>   6.06    0.005561        1854         3         1 wait4
>   5.83    0.005356           8       633       147 futex
>   4.15    0.003814           0     10020           write
>   3.25    0.002987         157        19           clone

[...]

> ------ ----------- ----------- --------- --------- ----------------
> 100.00    0.091800                 36339      2095 total
>
>
> So the main difference is that calls to 'open' take a lot longer.
> There's little we can do, other than come up with a good caching
> mechanism.

We should make sure these 1782 calls are all warranted (e.g., make sure
we don’t open the same file twice; this could be easily diagnosed by
looking at the output of ‘strace’.)

But then, as you say, it’s a process that opens lots of files.

We could cache package lookups, and maybe that’d help a little bit.
Currently we use ‘fold-packages’, which loads every single package
module, and then we look for a package named “coreutils” among them;
with a cache, we could directly load (gnu packages base) and its
dependencies.

Ludo’.