Re: [PATCH] build: Speed up .go compilation.

[Taylan Ulrich Bayırlı/Kammer]

address@hidden (Ludovic Courtès) writes:

> I have one concern: while running it peaked at 300 MiB resident in
> ‘top’, which is OK on many machines but still quite a lot.  I realize we
> have the same problem with ‘guix pull’ now, but that’s not great.  Part
> of the problem may be that modules are not GC’d.  But anyway, that’s 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 MB 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’ 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’.