Re: Guix size reduction work group

[zimoun]

Hi Ludo,

On Wed, 5 Feb 2020 at 16:18, Ludovic Courtès <address@hidden> wrote:

> > - 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?

It is hard to examine the graph with "guix size".
Sometimes, I am doing: "guix graph foo | grep"; especially with 'bag'
and friends. (I do not want to speak for Mathieu but he told me that
he is doing the same time to time. :-))

I agree that using "guix size" is already enough to find the culprits.


> > - 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.

IMHO, there is 2 directions: add more outputs or duplicate package variants.

For example Emacs:

for pkg in emacs-xwidgets emacs emacs-no-x-toolkit emacs-no-x emacs-minimal;
do
      echo $pkg
     guix size $pkg | tail -n1
     echo ""
done

emacs-xwidgets
total: 1222.4 MiB

emacs
total: 1003.7 MiB

emacs-no-x-toolkit
total: 522.6 MiB

emacs-no-x
total: 275.6 MiB

emacs-minimal
total: 204.2 MiB


And from my opinion, not enough packages are variant-ed.


> 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!

I have never thought, neither tried but is it possible to find and/or
build all the packages that 'inherit' from a specific one?


Cheers,
simon