pbzip2 isn't faster

Ryan Schmidt ryandesign at macports.org
Fri Apr 4 18:39:26 PDT 2014


On Apr 4, 2014, at 08:35, Eric A. Borisch wrote:

> I've definitely had success; the main thing to realize is that pbzip2 can only speed up decompression on a file created by pbzip2. (pbzip2 files are still valid bzip2 files.)

Thanks! That was the information I was missing. I’ve sent a message to the developer to add this information to their web page, since knowing that could have saved me some time.


> Do you see all cores being used during compression?

I had not yet tried compression, but I have now, and both compression and decompression work fine and use all my CPU cores.

Compressing the 2.8GB clang-3.5 tarball down to a 610MB bz2 file took bzip2 365 seconds, but took pbzip2 only 102 seconds. Excellent.

Decompressing the resulting file (and throwing the result away) with bzip2 took 83 seconds, while decompressing with pbzip2 took only 19 seconds.


On Apr 4, 2014, at 10:26, Eric A. Borisch <eborisch at macports.org> wrote:

> I have a (manually installed, linked against system libs) pbzip2 in /usr/local/bin/pbzip2. I configure macports (on install) with './configure BZIP2=/usr/local/bin/pbzip2’

This is precisely what I was interested in. Have you been using this configuration for long? Any problems? I set up something similar, but with pbzip2 installed from MacPorts, and I did have pbzip2 crash once. I’ll have to try it for longer and see how reliable it is.

Obviously the problem with using pbzip2 from MacPorts is that everything would break if pbzip2 were ever deactivated, including if it were ever upgraded.

Since the MacPorts build system now accommodates adding third-party software into the build, if pbzip2 works reliably, it might be nice to include it with MacPorts and use it at least for compression and decompression of the archives, if not also for bzip2 distfiles and patchfiles.



More information about the macports-users mailing list