Subject: Re: [bug#32980] [PATCH 0/2] Multiplexed build output from the daemon
From: [email-masked] (Ludovic Courtès)
To: [email-masked]
Date: Mon, 15 Oct 2018 23:27:55 +0200
List-Id: <debbugs-submit.debbugs.gnu.org>

Hello,

Ludovic Courtès <[email-masked]> skribis:

> The downside of the protocol is that it creates quite some overhead.  For
> example, when extracting a tarball, we see things like:
>
>   read(13, "gmlo\0\0\0\0", 8)             = 8
>   read(13, "5\0\0\0\0\0\0\0", 8)          = 8
>   read(13, "@ build-output 25935 29\ncoreutils-8.29/m4/fseterr.m4\n", 53) = 53
>   read(13, "\0\0\0", 3)                   = 3
>
> That is, a 29-byte message with a 24-byte header (plus the
> 8 + 8 + 3 = 19 bytes of the underlying protocol; see ‘process-stderr’.)

I timed “guix build -S binutils --check”, which includes the output of
“tar xvf” followed by “tar cvf”, and the timing difference is not
noticeable (of course the peak of CPU activity is caused by xz.)

Anyway I went ahead and pushed this as
f9a8fce10f2d99efec7cb1dd0f6c5f0df9d1b2df.

I changed “@ build-output” to “@ build-log”, and also adjusted
tests/status.scm since new tests had been added to that file in the
meantime.

Ludo’.