[bug#43516]

[Maxim Cournoyer]

Hi Leo!

> On Sat, Sep 19, 2020 at 01:03:57PM -0400, Maxim Cournoyer wrote:
> > The xz compression is slow; using multiple threads/cores yields a linear
> > performance improvement.
> >
> > * guix/packages.scm (patch-and-repack): Ensure xz is invoked with 
> > --threads=N
> > by setting the XZ_DEFAULTS environment variable.

> We tried this previous but reverted it because the archives were not
> bit-reproducible:

> https://git.savannah.gnu.org/cgit/guix.git/commit/?id=3e95125e9bd0676d4a9add9105217ad3eaef3ff0

Thanks for bringing this to my attention!  I've studied what others have done
about it, and found a solution that seems to work well on the OpenEmbedded
mailing list [0].  Debian uses something similar in their dpkg.

The important point is that xz will produce reproducible results as long as it
operates in either the single thread mode OR the multi-thread mode (we can't
go from one mode to another reproducibly).  So the following v2 patch ensures
we always use --threads=2 at a minimum, forcing the xz code path into
multi-thread operation.  The --memlimit=50% argument limits the RAM use of xz
to at most half of the available memory, which allows xz to reduce the number
of threads used to meet this requirement.

I've rebuilt the world or core-updates to test this and got impressive
results, such as when building the linux-libre source with 24 cores instead of
1:

$ time guix build --source linux-libre --check

With this change, on a 24 cores/32 GiB system: 24 cores used, 2.9 GiB max 
memory used, 36.76 s.
On master (same machine): 1 core used, 95 MiB max memory used, 4 m 10 s.

[0]  https://patchwork.openembedded.org/patch/170475/
[1]  https://sources.debian.org/src/dpkg/1.19.7/lib/dpkg/compress.c/#L566-L574

> It's really a shame... it would be nice to reduce the time used for XZ
> compression.

Seems we can have our cake and eat it, too!

Maxim