GNU bug report logs - #44254
Performance of package input rewriting

Previous Next

Full log

View this message in rfc822 format

From: Ludovic Courtès <ludo <at> gnu.org>
To: zimoun <zimon.toutoune <at> gmail.com>
Cc: 44254 <at> debbugs.gnu.org, Lars-Dominik Braun <ldb <at> leibniz-psychology.org>
Subject: bug#44254: Performance of package input rewriting
Date: Wed, 28 Oct 2020 15:19:56 +0100

Hi,

zimoun <zimon.toutoune <at> gmail.com> skribis:

> On Tue, 27 Oct 2020 at 14:26, Lars-Dominik Braun <ldb <at> leibniz-psychology.org> wrote:
>
>> Previously I have been doing this using package-input-rewriting, but starting
>> an environment containing python-jupyterlab alone took about 20s (warm caches,
>> all derivations in the store). Manually rewriting inputs by inheriting and
>> alist-delete’ing brings this down to 3s, which is pretty significant.
>> --no-grafts has not much of an impact (15s vs 2s) here. See
>> https://github.com/guix-science/guix-science/commit/972795a23cc9eb5a0bb1a2ffb5681d151fc4d4b0
>> for the exact changes.
>
> Is it not related to “#:deep? #t“ by default?  The default was #f.

Yes, that’s a possible culprit.  Try passing #:deep? #f if it works for
your use case.

Another thing to look at is the <package> object graph (as show by ‘guix
graph’).  Input rewriting can duplicate parts of the graph, which in
turn defeats package->derivation memoization.  Just looking at the
number of nodes in the graph can give hints.

Like Ricardo wrote, it’d be great it you could share a short reproducer.

Thanks,
Ludo’.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.