[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’.
Re: Guix size reduction work group, Pierre Neidhardt, 2020/02/08