GNU bug report logs - #33600
[PATCH 0/3] Defaulting to ci.guix.info (aka. berlin.guixsd.org)

Previous Next

Full log

Message #121 received at 33600 <at> debbugs.gnu.org (full text, mbox):

From: Pierre Neidhardt <mail <at> ambrevar.xyz>
To: Ludovic Courtès <ludo <at> gnu.org>
Cc: guix-devel <at> gnu.org, Hartmut Goebel <h.goebel <at> crazy-compilers.com>,
 33600 <at> debbugs.gnu.org
Subject: Re: Compressing nars with lzip or similar
Date: Sat, 15 Dec 2018 13:17:05 +0100

[Message part 1 (text/plain, inline)]

I've done some quick research over the various options.

- lzip: better than gz and bzip2 for sure, possibly better than xz (at
least according to the author).

- plzip: for "parallel lzip".  With 4 threads I was able to compress
icecat 2.5x faster.  It used 5x more memory though.  The compression
ratio is 1-2% worse.

- lrzip: it would crash whenever I would change the compression level.
  Seems less stable.  It's as fast as plzip, while being 1-2% less
  compressed.  I don't think it's worth using.

All in all, lzip is a definite win over most options.  The main question
is: lzip or plzip?

In my opinion it makes more sense to use plzip, gotta put those cores to
some use (on the user side at least)!  Not sure what the build farm
would think about this though.

Finally, plzip can be quite memory-intensive.  When passed "--threads=1"
however, it gets closer to lzip (bit faster, bit more memory).  So maybe
the ideal would be to support plzip with a user-settable "threads" option.

Thoughts?

--
Pierre Neidhardt
https://ambrevar.xyz/

[signature.asc (application/pgp-signature, inline)]

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.