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

[Matias Fonzo]

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 <address@hidden> 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?
>