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

Previous Next

Full log

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

From: Ricardo Wurmus <rekado <at> elephly.net>
To: Lars-Dominik Braun <ldb <at> leibniz-psychology.org>
Cc: 44254 <at> debbugs.gnu.org, bug-guix <at> gnu.org
Subject: Re: bug#44254: Performance of package input rewriting
Date: Tue, 27 Oct 2020 20:58:14 +0100

Lars-Dominik Braun <ldb <at> leibniz-psychology.org> writes:

> this issue is similar to https://issues.guix.gnu.org/41702, but I’m not sure
> it’s exactly the same. For guix-science I’m trying to provide some packages
> like python-jupyterlab, which depend on a mix of packages from guix proper and
> newer versions of packages already included in guix proper. Thus I need to
> rewrite inputs of the former to the latter. (Because Python only propagates
> dependencies and thus collisions would occur.)
>
> 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.

Could you show us a concrete example?  Input rewriting is recursive and
will traverse the whole package graph by default, even if you *know*
that, say, GCC doesn’t need to be rewritten.

For the more generic “package-mapping” you can provide a “cut?”
procedure to determine when to stop recursion.  Perhaps this would make
things faster in your case?

-- 
Ricardo

Previous Next

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