From mboxrd@z Thu Jan 1 00:00:00 1970 From: zimoun Subject: Re: Guix size reduction work group Date: Wed, 5 Feb 2020 17:11:17 +0100 Message-ID: References: <87pneul50i.fsf@ambrevar.xyz> <87blqdnjuv.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Return-path: Received: from eggs.gnu.org ([2001:470:142:3::10]:51369) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1izNH5-0006CG-I3 for guix-devel@gnu.org; Wed, 05 Feb 2020 11:11:37 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1izNH4-0000dH-9k for guix-devel@gnu.org; Wed, 05 Feb 2020 11:11:35 -0500 In-Reply-To: <87blqdnjuv.fsf@gnu.org> List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+gcggd-guix-devel=m.gmane-mx.org@gnu.org Sender: "Guix-devel" To: =?UTF-8?Q?Ludovic_Court=C3=A8s?= Cc: Guix Devel Hi Ludo, On Wed, 5 Feb 2020 at 16:18, Ludovic Court=C3=A8s wrote: > > - Improve the tooling. In my experience, guix graph is quickly unusabl= e > > 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. > > =E2=80=98guix size=E2=80=99 is key here: it=E2=80=99s 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=E2=80=99t. Later on Nixpkgs had a large= part > of its packages split in several outputs (more than we do). From what I > heard, it wasn=E2=80=99t as fruitful as they had hoped it would be in ter= ms 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=E2=80=99s something that requires constant care,= every > time we add a package or modify an existing one. It=E2=80=99s 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