guix-devel
[Top][All Lists]
Advanced

[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’.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]