Hello, Congratulations for the move. :-)
Note that the values of `xz -9' are not the same as the values used for `lzip -9'. If you want to achieve the same or even more, you could try adjusting the match length and the dictionary size: lzip -m64 -s64MiB On Wed, 18 Jul 2018 15:47:57 +0100 Ralph Corderoy <[email protected]> wrote: > > Having read http://lzip.nongnu.org/xz_inadequate.html I'm happy to > move away from xz(1), having been lured by coreutils adding it > originally. So I picked a random Gimp XCF file already xz'd and > compared sizes. > > 55,569138 gimp > 21,001368 xz -9 > 23,299403 lzip -9 23,299403 / 21,001368 = 1.109 > > +~11% is disappointing given > https://www.nongnu.org/lzip/lzip_benchmark.html#xz > This is lzip 1.20-1 and lz4 1:1.8.2-2 on Arch Linux. > > I tried a couple dozen more from `locate | shuf' and lzip was narrowly > ahead on all of those, as expected, so it must have been `pot unluck'! > > Unfortunately, I can't pass the XCF on, and couldn't find a mechanism > that would dump how each compressor coped with the same bytes for > comparison. > > Mapping each byte onto another random byte through the file, I find > that compresses less well, but still with lzip about ~11% larger than > xz. > > 23,135884 xz -9 > 25,741498 lzip -9 25,741498 / 23,135884 = 1.113 > > I could arrange to pass this second, mapped, file on privately if > anyone's interested. > > Is there a known reason why xz does noticeably better is some > situations like this one? > _______________________________________________ Lzip-bug mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/lzip-bug
