[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#44254: Performance of package input rewriting
From: |
Ricardo Wurmus |
Subject: |
bug#44254: Performance of package input rewriting |
Date: |
Tue, 27 Oct 2020 20:58:14 +0100 |
User-agent: |
mu4e 1.4.13; emacs 27.1 |
Lars-Dominik Braun <ldb@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