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
_______________________________________________
Lzip-bug mailing list
[email protected]
https://lists.nongnu.org/mailman/listinfo/lzip-bug
