[Lzip-bug] Want to Jettison xz(1), But Size Matters.

[Ralph Corderoy]

Hi,

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?

-- 
Cheers, Ralph.
https://plus.google.com/+RalphCorderoy