[systemd-devel] [systemd-commits] 14 commits - configure.ac Makefile.am Makefile-man.am man/coredump.conf.xml src/core src/journal src/shared

Uoti Urpala uoti.urpala at pp1.inet.fi
Fri Jun 27 09:34:29 PDT 2014


On Fri, 2014-06-27 at 16:17 +0200, Zbigniew Jędrzejewski-Szmek wrote:
> Hm, I did some testing, and I'm not convinced that XZ is the right
> compressor for the job.
> 
> First I generated a 1GB coredump of Python with random patterns. It
> takes 20 minutes (!)  to compress with XZ 9, and 11.5 min with XZ 6,
> ~1 min with gzip 6, the same with gzip 9. The gain from XZ compression
> is an increase in compression: gzip saves 7%, XZ saves 12%.
> 
> Second I generated a second 1GB coredump, highly compressible.
> XZ 9 → 99.8%, 120 s; XZ 6 → 99.8%, 120 s;
> gzip 6 → 99.6%, 11 s; gzip 9 → 99.6%, 13 s;
> 
> So the tradeoffs seem all wrong.

I think this is a bad comparison.

You tested mostly random content (which no compressor will compress) and
trivially compressible content (which anything will highly compress);
neither allows meaningfully comparing compression ratios. If you want to
quote compression ratios, you need more realistic content.

You didn't test XZ levels lower than 6, even though you tested gzip
levels lower than 9. XZ level 6 is a much higher than gzip level 9. If
you want higher speed, you should test with lower XZ levels.

For time/compression ratio tradeoff with large files, lrzip could be the
best. That probably doesn't make it the best fit for systemd use though,
due to other issues such as library integration and memory use. Or at
least not the best fit to use as default; it could be a marked
improvement over other alternatives in particular cases where an admin
could configure it as an external compressor.




More information about the systemd-devel mailing list