From mboxrd@z Thu Jan 1 00:00:00 1970 From: ludo@gnu.org (Ludovic =?utf-8?Q?Court=C3=A8s?=) Subject: Re: Guile 2.2 .go files are larger Date: Thu, 27 Apr 2017 16:03:36 +0200 Message-ID: <87zif254nb.fsf@gnu.org> References: <8737d07f7c.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:4830:134:3::10]:57488) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1d3k1I-0004Ov-MS for guix-devel@gnu.org; Thu, 27 Apr 2017 10:03:45 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1d3k1E-0003jt-GD for guix-devel@gnu.org; Thu, 27 Apr 2017 10:03:44 -0400 In-Reply-To: (Andy Wingo's message of "Mon, 24 Apr 2017 10:24:55 +0200") 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.org@gnu.org Sender: "Guix-devel" To: Andy Wingo Cc: guix-devel Hi! Andy Wingo skribis: > On Sat 22 Apr 2017 15:19, ludo@gnu.org (Ludovic Court=C3=A8s) writes: > >> The closure of Guix built with 2.0 is 193.8 MiB; when built with 2.2, >> it=E2=80=99s 311.8 MiB. Guix itself goes from 66 to 150=C2=A0MiB: >> >> $ du -ms /gnu/store/jh07pwbyf5dbpdd5q0nvgagqkgmh76nh-guix-0.12.0-9.25a4/= lib/guile/2.2 >> 101 /gnu/store/jh07pwbyf5dbpdd5q0nvgagqkgmh76nh-guix-0.12.0-9.25a4/lib/g= uile/2.2 >> $ du -ms /gnu/store/rnpz1svz4aw75kibb5qb02hhccy2m4y0-guix-0.12.0-7.aabe/= lib/guile/2.0 >> 24 /gnu/store/rnpz1svz4aw75kibb5qb02hhccy2m4y0-guix-0.12.0-7.aabe/lib/gu= ile/2.0 > > Before we begin, some general notes. My understanding is that the heap > usage corresponding to an individual Guix process will be lower, both > due to allocation of read-only data in read-only, shareable sections of > the .go ELF files, allocation of read-write data in packed sections > known to the GC but not managed by GC, and various optimizations that > can eliminate or simplify some heap allocations (closure optimization > among them). In short my understanding is that Guile 2.2 (and systems > built on it) should have a smaller run-time footprint than Guile 2.2. Yes of course. >> Would you have any suggestions to shrink the ELF files a bit? > > Why? Have you compared gzipped or lzipped sizes? I don't want to put > effort in here that's not worth it :) --8<---------------cut here---------------start------------->8--- $ du -ms $(./pre-inst-env guix pack guile@2.0) 35 /gnu/store/25ppdmridc8i1j771s9c498y1sr9xfzb-tarball-pack.tar.gz $ du -ms $(./pre-inst-env guix pack guile@2.2) 40 /gnu/store/3fkhdpfpjjn8088fs0dxgb6hi38ac46m-tarball-pack.tar.gz --8<---------------cut here---------------end--------------->8--- (Of course the difference is also due to the additional source code in 2.2.) > Part of it is that our page alignment is 64 kB and so average wasteage > per .go is 32kB, and there are a lot of .go files. These are just zero > bytes though. OK. It might be that file systems can store sparse files reasonably efficiently. > If you look at an individual file, you can use readelf to see things, or > that old ELF visualizer I wrote: > > https://wingolog.org/elf-mapper/ > > Here's a map of gnu/packages/curl.go: > > https://wingolog.org/pub/elf/elf-JWXYrI.png > > I think stripping the .debug_* stuff won't get you much of anywhere. > > Stripping arities info could reduce size by 10%. We could figure out a > different way to represent arities that takes less space. > > Compiling all the .go files together (requires Guile hacking) could > remove that per-go 64kB alignment overhead. Alternately we could do > what GNU tools / ld.so do which maps the linear sequence of bytes in the > file to aligned segments in memory. > > Honestly though I would punt. It's not a run-time issue. I don't think > it's a transport issue. It's only a disk space issue. I personally > don't plan to spend time on it but am happy to point out possibilities > to people that will do so. Sure, I understand. I was just wondering if there was some low-hanging fruit here. Thanks for your feedback! Ludo=E2=80=99.