On Thu, Feb 28, 2013 at 5:53 PM, Antonio Diaz Diaz <ant_d...@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. _______________________________________________ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
