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:57:04 +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]:46579) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1d2Zo7-0004sb-M9 for guix-devel@gnu.org; Mon, 24 Apr 2017 04:57:20 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1d2Zo2-0006l2-Uf for guix-devel@gnu.org; Mon, 24 Apr 2017 04:57:19 -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: Ludovic =?utf-8?Q?Court=C3=A8s?= Cc: guix-devel On Mon 24 Apr 2017 10:24, Andy Wingo writes: > 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 ^ lower than Guix-on-Guile-2.0, I mean > 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. Er, than smaller footprint than Guile 2.0. Sorry for the confusion :)