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 <[email protected]> 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.

_______________________________________________
macports-users mailing list
[email protected]
https://lists.macosforge.org/mailman/listinfo/macports-users

Reply via email to