XZ embedded bug unpacking linux-3.8.tar.xz

[Denys Vlasenko]

On Thu, Feb 28, 2013 at 5:53 PM, Antonio Diaz Diaz <ant_diaz at teleline.es> wrote:
> You didn't try lzip but plzip, which is beta software. And of course,
> parallel versions of lzip or xz compress less than standard versions because
> they split data in blocks before compressing it.
>
> But even so there is someting wrong with your test. Maybe your C++ compiler
> produces slower executables than the C compiler, or you used an old version
> of plzip or lzlib... I have just retried to compress gcc-4.7.2.tar (just in
> case) and in my single-processor machine, plzip (using the default
> compression level) is faster(6:16) than both lzip(6:37) and xz(7:32), just
> as expected.
>
> Why is this expected? Because both lzip and plzip use a default value for
> --match-length smaller than the equivalent option in xz (36 vs 64), and
> plzip sees a smaller effective dictionary size because it splits the input
> data in blocks.

Parallel compression benchmark isn't interesting: the task is trivially
parallelizable, so the speedup will be nerly exactly proportional
to the number of CPUs.

Compare one-thread xz against one-thread lzip.