[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: having trouble modifying guix-daemon
From: |
Ludovic Courtès |
Subject: |
Re: having trouble modifying guix-daemon |
Date: |
Fri, 05 Jul 2019 23:41:54 +0200 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/26.2 (gnu/linux) |
Hi Robert,
Robert Vollmert <address@hidden> skribis:
>> On 1. Jul 2019, at 12:28, Ludovic Courtès <address@hidden> wrote:
>>
>> Hello,
>>
>> Robert Vollmert <address@hidden> skribis:
>>
>>> I’d like to improve the debug output here more generally: At (high enough)
>>> debug level, it seems to make sense to log every operation. What I’m unclear
>>> on here is whether it’s better to do that client or server side, what do you
>>> think? The spots would be
>>>
>>> (a) nix/nix-daemon/nix-daemon.cc:performOp (inside each start/stopWork pair)
>>> (b) guix/store.scm:operation (next to record-operation)
>>>
>>> I have a slight preference for (b) since it avoids the sending data back
>>> and forth.
>>
>> In my experience I rarely need to log every operation (e.g., every RPC),
>> and when I do, I add a well-placed ‘pk’. :-)
>
> That’s hardly something you’d expect a guix system user to do that’s trying
> to understand why guix pull is taking forever though, is it?
No, but I don’t expect users to profile Guix anyway.
I didn’t understand your request had to do with ‘guix pull’. It “takes
forever” for two reasons:
1. The “Computing Guix derivation” phases takes a bit less than 1mn on
my laptop; it runs most of the target Guix through the interpreter,
which is why it’s this slow. Optimizing it is high on my list, but
it’s not that easy.
2. The rest is about downloading substitutes or, if you’re unlucky,
compiling part of Guix. As it turns out, Guile’s compiler since
2.2 is unreasonably resource-intensive when compiling simple code
like gnu/packages/*.scm. Again, that needs work; if you want to
fiddle with graph processing algorithm, this is for you.
The daemon is not responsible for the slowness here.
Thanks,
Ludo’.