guix-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Guix size reduction work group


From: Ludovic Courtès
Subject: Re: Guix size reduction work group
Date: Wed, 05 Feb 2020 16:18:16 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux)

Hi!

Pierre Neidhardt <address@hidden> skribis:

> Shall we start a work group to fix the issue?
>
> - Write a blog article to explain the issue and a detailed process on
>   how to fix it.  (Embed it to the manual.)

The “Submitting Patches” section mentions closure size specifically.  Is
there anything you think we should add there?

> - Improve the tooling.  In my experience, guix graph is quickly unusable
>   with a high number of nodes.  Maybe d3.js could be leveraged to add a
>   filtering system, or a way to click on nodes to hide them and all
>   their children.

‘guix size’ is key here: it’s a profiler, exactly what we need IMO.
WDYT?

> - How do we compare to Nix?

A few years back we were doing better because we used separate outputs
in key places where Nixpkgs didn’t.  Later on Nixpkgs had a large part
of its packages split in several outputs (more than we do).  From what I
heard, it wasn’t as fruitful as they had hoped it would be in terms of
closure size, but it might still be better than what we have, dunno.

The thing is, I think it’s something that requires constant care, every
time we add a package or modify an existing one.  It’s very easy to lose
benefits that had been previously obtained through hard work!

At any rate, I agree we need to improve!

Ludo’.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]