From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andy Wingo Subject: Re: Guile 2.2 .go files are larger Date: Mon, 24 Apr 2017 10:24:55 +0200 Message-ID: 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]:39036) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1d2ZJZ-0005aw-Fu for guix-devel@gnu.org; Mon, 24 Apr 2017 04:25:46 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1d2ZJW-0004fV-BU for guix-devel@gnu.org; Mon, 24 Apr 2017 04:25:45 -0400 In-Reply-To: <8737d07f7c.fsf@gnu.org> ("Ludovic =?utf-8?Q?Court=C3=A8s=22'?= =?utf-8?Q?s?= message of "Sat, 22 Apr 2017 15:19:03 +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: Ludovic =?utf-8?Q?Court=C3=A8s?= Cc: guix-devel 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/l= ib/guile/2.2 > 101 /gnu/store/jh07pwbyf5dbpdd5q0nvgagqkgmh76nh-guix-0.12.0-9.25a4/lib/gu= ile/2.2 > $ du -ms /gnu/store/rnpz1svz4aw75kibb5qb02hhccy2m4y0-guix-0.12.0-7.aabe/l= ib/guile/2.0 > 24 /gnu/store/rnpz1svz4aw75kibb5qb02hhccy2m4y0-guix-0.12.0-7.aabe/lib/gui= le/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. > 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 :) 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. 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. Andy