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

Previous Next

Full log

Message #20 received at 44254 <at> debbugs.gnu.org (full text, mbox):

From: Lars-Dominik Braun <ldb <at> leibniz-psychology.org>
To: Ricardo Wurmus <rekado <at> elephly.net>,
 Ludovic Courtès <ludo <at> gnu.org>
Cc: 44254 <at> debbugs.gnu.org, zimoun <zimon.toutoune <at> gmail.com>
Subject: Re: bug#44254: Performance of package input rewriting
Date: Fri, 30 Oct 2020 09:42:45 +0100

[Message part 1 (text/plain, inline)]

Hi,

> Yes, that’s a possible culprit.  Try passing #:deep? #f if it works for
> your use case.
Yeah, that brings it down to ~8s, which is still alot.

> 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.
Aha, it’s 913 nodes without rewriting, 13916 with rewriting (#:deep? #t) and
4286 with rewriting (#:deep? #f) as determined by a rather ad-hoc `guix graph
-L . -t package python-jupyterlab | grep 'shape = box' | wc -l`. That seems way
too much. Does that mean I’m using package rewriting in the wrong way or is
that a bug?

Unfortunately I don’t have a short reproducer right now. I’ll look at the graph
more closely to figure out which parts are actually duplicated. Maybe I can
create a reproducing testcase with more information.

Cheers,
Lars

[signature.asc (application/pgp-signature, inline)]

Previous Next

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