GNU bug report logs - #54539
[PATCH 0/6] Start breaking up import cycles

Previous Next

Full log

View this message in rfc822 format

From: zimoun <zimon.toutoune <at> gmail.com>
To: Maxime Devos <maximedevos <at> telenet.be>
Cc: Liliana Marie Prikler <liliana.prikler <at> ist.tugraz.at>, 54539 <at> debbugs.gnu.org
Subject: [bug#54539] [PATCH 0/6] Start breaking up import cycles
Date: Fri, 25 Mar 2022 20:33:28 +0100

Hi Maxime,

On Fri, 25 Mar 2022 at 18:46, Maxime Devos <maximedevos <at> telenet.be> wrote:
> zimoun schreef op vr 25-03-2022 om 18:05 [+0100]:

> > To be honest, I am not sure to understand the aim of reorganizing the
> > modules... I mean, to me, the only important metrics is the
> > performance of the end-user.  If there is no performance improvement
> > when cutting cycle, then it appears to me pointless to cut cycles. :-)
>
> FWIW, there are three goals here:
>
>   * Allowing writing stuff like
>
>     (use-modules (gnu packages ncurses))
>     (package
>       (name "some-terminal-app")
>       [...]
>       ;; Work-around the ‘search path of dependencies not propagated’ bug.
>       (native-search-paths (package-native-search-paths ncurses)))
>
>     without getting 'unbound variable' errors.
>     Alternatively, the search-path-specification could be defined in,
>     say, (guix search-paths) next to $PATH but that proposal seems
>     to have been rejected.
>
>   * Making "compute-guix-derivation" faster by reducing the number of
>     (uncompiled!) package module files it needs to load.
>
>   * Eventually making the ‘incremental compilation’ by fine-grained derivations
>     proposal from the ‘Faster "guix pull" by incremental compilation and
>     non-circular modules?’ thread [0] feasible.

Thanks for the detailed and clear explanations.  It was my initial
understanding that cutting cycles can improve the performances, and
IMHO, timings are required for comparing apple to apple; as I tried to
explain [1].  Then the thread have let me the impression that the
performance improvement was not the aim -- thanks for clarifying.

1: <https://issues.guix.gnu.org/54539#12>

> (*) FWIW, on my machine, "guix show guix" takes 1.6s.

To be precise, "guix show guix" could be drastically improved by
adapting the already existing package.cache, i.e., resume the lengthy
work of <https://issues.guix.gnu.org/39258>. :-)

However, such cache would be useless for "guix show -L path/to/others
foo" where performance can be really poor; especially on spinning hard
disk.  Well, thanks for working on that by trying to tackle the cycle
of modules.


Cheers,
simon

Previous Next

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