wade@sdacs.ucsd.EDU (Wade Blomgren) (03/11/89)
Here are some actual figures on the relative performance of various
compression and encoding schemes. The file used for the test was
the actual StuffIt 1.5.1 application. (In cases where a unix tool is used
directly on the Mac file, the Mac file was first converted to "old" MacBinary)
Original File Size 117632 bytes
Compression only:
Change from Original
Unix compress 82169 -30.0%
Stuffit 1.5.1 87424 -25.7
PackItIII 99200 -15.7
Encoding only, no compression:
Unix btoa hex encoding: 148052 +25.9%
BinHex 4.0 .hqx encoding: 157838 +34.2%
StuffIt 1.5.1 .hqx encoding: 161959 +37.6%
Unix uuencode hex encoding: 162094 +37.8%
Compression, followed by encoding
compress, btoa 104089 -11.5%
StuffIt, btoa 110722 - 5.9%
compress, uuencode 113234 - 3.7%
StuffIt, BinHex .hqx 119051 + 1.2% **
Stuffit, uuencode 120482 + 2.4%
Stuffit, StuffIt .hqx 120907 + 2.7% **
PackItIII, BinHex .hqx 134714 +14.5%
PackItIII, StuffIt .hqx 136785 +16.3%
**note that once a file is compressed, the lack of run length coding in
StuffIt's implementation of BinHex has very little negative effect
From this small example it seems that btoa encoding is indeed an efficient
alternative to either form of BinHex (with run length coding, as in BinHex
4.0, or without, as in StuffIt). It results in an 8.4% savings over
the generally accepted StuffIt/StuffIt .hqx format. How much is 8.4%?
In this case (10185 bytes difference), my guess would be about 70 seconds
on a 95% efficient Zmodem download at 1200 baud. Which could add up. An
even less efficient setup, which I actually tried out, (kermit, short packets,
1200 baud) took over 2 minutes to transfer 10185 bytes.
Now, we can't just go proposing new standards left and right.
But btoa does seem to work a bit better, at least in this isolated case.
Wade Blomgren
wade@sdacs.ucsd.edu