Re: [PATCH] maint: use an optimal-for-findutils xz compression setting

[Jim Meyering]

On Sun, Oct 29, 2017 at 2:24 PM, Bernhard Voelker
<address@hidden> wrote:
> On 10/28/2017 08:06 PM, Andreas Metzler wrote:
>> On 2017-10-28 Bernhard Voelker <address@hidden> wrote:
>>> * cfg.mk: Set XZ_OPT = -7e (determined empirically).
>>> The compressed tarball size is identical to the default settings (-9e),
>>> but using -9e would force every decompression process to use 48 MiB
>>> more memory.
>> [...]
>>
>> I do not think this is a good tradeoff between increasing code size
>> (cfg.mk) vs possible performance improvement.
>
> Thanks for your comments.
> well, it's just one line of code; the rest are comments, so therefore
> I wouldn't bother.
>
>> - Do you expect somebody
>> is going to use a system for building find release tarballs that is
>> totally memory starved and wil be saved by an additional 48 MiB?
>
> GNU findutils are basic enough that they are likely to be built on
> very limited systems/platforms as well.  And if someone actually runs
> into that problem, then he would be very grateful for this.
>
>> OTOH -7e is almost two times *slower* than the default. 5.74 seconds vs
>> 3.77 on i5-6500.
>
> This is the time for creating the compressed tarball, right?  This is done
> only once on a maintainer's system.  I didn't see any noticeable difference
> during extraction (on my i5-4570) though.
>
> Coreutils uses -8e for the same reason [1], so I think it's worth here as
> well.  I'll adjust to -8e then, WDYT?
>
> [1] https://git.sv.gnu.org/cgit/coreutils.git/tree/cfg.mk?id=61a8b5cb56#n37

I like the idea of optimizing for reduced size of compressed tarball,
but without imposing an unnecessarily high run-time memory requirement
to uncompress. Before I changed the coreutils setting, there had been
at least a couple reports that people had been unable to decompress on
memory-constrained systems.