From mboxrd@z Thu Jan 1 00:00:00 1970 From: taylanbayirli@gmail.com (Taylan Ulrich =?utf-8?Q?Bay=C4=B1rl=C4=B1?= =?utf-8?Q?=2FKammer?=) Subject: Re: [PATCH] build: Speed up .go compilation. Date: Sun, 10 Jan 2016 11:24:19 +0100 Message-ID: <8760z1ybos.fsf@T420.taylan> References: <87lha3rx04.fsf@T420.taylan> <87mvsgxpef.fsf@T420.taylan> <87ziwgf1b4.fsf@gnu.org> <87egdqy24m.fsf@T420.taylan> <87bn8u76tl.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]:40875) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aIDAd-0007bZ-H0 for guix-devel@gnu.org; Sun, 10 Jan 2016 05:24:24 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aIDAc-0001QX-Ko for guix-devel@gnu.org; Sun, 10 Jan 2016 05:24:23 -0500 In-Reply-To: <87bn8u76tl.fsf@gnu.org> ("Ludovic \=\?utf-8\?Q\?Court\=C3\=A8s\=22'\?\= \=\?utf-8\?Q\?s\?\= message of "Sat, 09 Jan 2016 22:59:18 +0100") 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-bounces+gcggd-guix-devel=m.gmane.org@gnu.org To: Ludovic =?utf-8?Q?Court=C3=A8s?= Cc: guix-devel@gnu.org ludo@gnu.org (Ludovic Court=C3=A8s) writes: > I have one concern: while running it peaked at 300=C2=A0MiB resident in > =E2=80=98top=E2=80=99, which is OK on many machines but still quite a lot= . I realize we > have the same problem with =E2=80=98guix pull=E2=80=99 now, but that=E2= =80=99s not great. Part > of the problem may be that modules are not GC=E2=80=99d. But anyway, tha= t=E2=80=99s a > scalability problem. > > What do people think? Well, my observation while testing guix pull was that before, one would get several Guile processes each taking up about 100=C2=A0MB memory if I remember correctly. (As many processes as one has cores.) So for dual- or quad-core devices we're not making things (much) worse, but maybe some single-core devices with little memory will now have problems. If it becomes urgent, we could partition the files to be compiled into subsets and use a few Guile processes to compile them. Could actually speed things up on multi-core devices, and would still be much faster than one-process-per-file on single-core. > A lesser concern is the long command-line passed to compile-all.scm, > notably because Emacs=E2=80=99 compilation-mode runs regexps on each line= , and > that takes time proportional to the length of the line, so that leads > Emacs to hang for a second when it sees that line. Silly. ;-) I use M-x shell so I didn't have the slowness, but it still annoyed me actually, if only because it's ugly. (It's also output every time one runs 'make', even if all .go files are up to date.) What about silencing it, like: make-go: $(MODULES) guix/config.scm guix/tests.scm @echo "Compiling Scheme modules..." ; \ unset GUILE_LOAD_COMPILED_PATH ; \ ... > Thanks! > Ludo=E2=80=99.