On Sun, Oct 29, 2017 at 2:24 PM, Bernhard Voelker <m...@bernhard-voelker.de> wrote: > On 10/28/2017 08:06 PM, Andreas Metzler wrote: >> On 2017-10-28 Bernhard Voelker <m...@bernhard-voelker.de> 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.