Compression Comparison Guide

[Adrian Wong]

Originally Posted by CeeJay

Adrian ...

If you're trying to find the fastest compressor, you really need to test LZOP http://www.lzop.org/
Other compression comparisons consistently rank it as the fastest compressor on the planet.

Seeing Peter Cranstone post here, impels me to point out that rojakpot.com is not being served gzip-compressed and you could save a huge amount of bandwidth by doing that.
And the site would load a lot faster to boot.

Hello CeeJay!

Thanks for the tip. Will go check it out ASAP. Maybe I can add it to the Fastest test results before I get the results of the other tests.

[Adrian Wong]

Originally Posted by MisterE

You fault the StuffIt (X) format for not compressing certain file types (such as MP3 files), but there is a default setting in StuffIt (the application) to not compress already compressed items (I believe the windows version says "Do not Recompress Items"). If you uncheck this option and re-run your tests you will see results more comparable to the other compression applications. But as noted above, the time and effort used to compress files that have little redundancy can be better spent, so the StuffIt app defaults to adding the files to the archive without further compression.

Hello Eric,

Just checked the StuffIt settings. It looks like the "Do not Recompress Compressed Items" setting was NOT enabled in my tests. At least, it doesn't seem to be enabled now but since I did not change any settings since, that should be the case and the current results should be valid.

[MisterE]

Hey Adrian,

I stand corrected... The Don't Compress Already Comrpessed Items setting only applies to other formats that StuffIt can create (ie: zip, gzip, StuffIt 5).

The StuffIt X format excludes certain files that are typically difficult to compress (ie: .mp3, .mov). These files are added to the archive without compression. I knew this was the case with the Mac version, but I was under the impression that with the Windows versions of StuffIt, the Don't Recompress option affected all compression formats. (I test the Mac version...)

Again, the reasoning for excluding these files is that for general use, in most cases the effort taken to compress a lossy-compressed file gives little return. (JPEG being the exception - we get great compression in JPEGs!)

I expect that we will give users more control over this setting when using the StuffIt X format in future versions.

--Eric K

[Olle P]

Originally Posted by Adrian Wong

The efficiency ratings actually serves to prove a point - compression speed is also important. Most of the designers of such software placed too much emphasis on compression performance.

Of course, compression performance IMHO is very important but so is compression speed. I think some emphasis should be given towards compression speed.

I'd say there's a fairly straightforward relationship where the computing time grows exponentially with the compression rate, no matter what algorithm is used.
For a comparison in this test it would be nice to also know the time needed to do a straight copy, not using any compressor.
This would show how much extra time it takes to save some space. I'd guess that the extra time is neglectable when compressing a small amount of data on a "fast" setting, and then be the major factor when opting for maximum compression.

The only conclusions I can draw from the comparison, as presented this far, are:
- Win RK doesn't opt for speed.
- Stuffit is crap for anything but JPEG-files.

I'm looking forward for the maximum compression test.

Cheers
Olle

[Adrian Wong]

Originally Posted by Olle P

I'd say there's a fairly straightforward relationship where the computing time grows exponentially with the compression rate, no matter what algorithm is used.
For a comparison in this test it would be nice to also know the time needed to do a straight copy, not using any compressor.
This would show how much extra time it takes to save some space. I'd guess that the extra time is neglectable when compressing a small amount of data on a "fast" setting, and then be the major factor when opting for maximum compression.

The only conclusions I can draw from the comparison, as presented this far, are:
- Win RK doesn't opt for speed.
- Stuffit is crap for anything but JPEG-files.

I'm looking forward for the maximum compression test.

Cheers
Olle

Straight copy? Hmm.. I used two different hard drives to minimize the effect of the controller on their performance. Also, I used a slow PC to reduce the effect of the hard drives on the results. In effect, I'm increasing the bias on the actual compression, instead of hard drive activity.

BTW, I think the effect of hard drive activity will be more pronounced during the fast tests since the processor needs far less time compressing it and the compressed archive will be bigger.

Will get the other results out as soon as I can. Been travelling a lot these days and I will still need to travel more in the coming weeks.

[Olle P]

Originally Posted by Adrian Wong

Straight copy? Hmm.. I used two different hard drives to minimize the effect of the controller on their performance.

Still, the actual access time to read/write can't be neglected.

Originally Posted by Adrian Wong

BTW, I think the effect of hard drive activity will be more pronounced during the fast tests...

... which I also pointed out, with the addition that it also requires somewhat "small" files so that the computer won't need to use the virtual RAM (HDD) to temporarily store half-baked calculations during the compression.

Cheers
Olle

[Adrian Wong]

Originally Posted by Olle P

Still, the actual access time to read/write can't be neglected.
... which I also pointed out, with the addition that it also requires somewhat "small" files so that the computer won't need to use the virtual RAM (HDD) to temporarily store half-baked calculations during the compression.

Cheers
Olle

Correct, but as long as the variables are minimized and kept constant, the results should not be affected much.

Also, some compressors compress directly to the archive, instead of compressing to a temporary folder first and then copying the final archive out. In such cases, they would be penalized if we deduct the time to copy from one hard drive to another.

This is one of the reasons why I did it this way. Although the effect of the hard drive system is minimized, there should also be no manipulation of the results if possible. In this case, deducting the access/write time will skew the results in favour of compressors that compress to a temporary folder first.

[Olle P]

Originally Posted by Adrian Wong

... deducting the access/write time will skew the results in favour of compressors that compress to a temporary folder first.

Quite the opposite I'd say!
You deduct the time it takes to make one full size copy. Saving to a temporary folder means making two copies, which takes almost twice as long.

In theory a compressor that doesn't save to a temporary folder might produce a compressed archive faster than it takes to make a straight copy, if the CPU power needed for the calculations doesn't interfere with the data transfer.

As you yourself previously wrote; time is also a factor! If I need to quickly copy something for archiving or distribution, then I'm interested in knowing how much longer it will take me to compress the data and do the copy, saving ~10% space, compared to making a straight copy.
When using a slow media for the file transfer it's almost always better to compress as much as possible first. (I vividly recall downloading 100MB files through a null modem at 10MB/h...)

Cheers
Olle

[Adrian Wong]

Originally Posted by Olle P

Quite the opposite I'd say!
You deduct the time it takes to make one full size copy. Saving to a temporary folder means making two copies, which takes almost twice as long.

In theory a compressor that doesn't save to a temporary folder might produce a compressed archive faster than it takes to make a straight copy, if the CPU power needed for the calculations doesn't interfere with the data transfer.

As you yourself previously wrote; time is also a factor! If I need to quickly copy something for archiving or distribution, then I'm interested in knowing how much longer it will take me to compress the data and do the copy, saving ~10% space, compared to making a straight copy.
When using a slow media for the file transfer it's almost always better to compress as much as possible first. (I vividly recall downloading 100MB files through a null modem at 10MB/h...)

Cheers
Olle

Err... there are basically two ways these compressors work. Either they directly write to the archive as they compress the files.. or they compress to a temporary folder, usually on the OS drive and then write it out to the archive, which in this case is on another hard drive.

Yes, saving to a temporary folder will take longer, but not really twice as long. In fact, moving the archive from the temporary folder to the actual folder takes only seconds, which is far shorter than the compression time.

Actually, for both methods, the CPU does not actually interfere with the data transfer. The only difference between the two methods is that the "temporary storage" method needs to move the final archive out to the actual folder. That's it. Nothing else differs, as least as far as the CPU is concerned.

Yes, time is a factor, which is why it would not be fair to arbitrarily deduct the time it takes to copy the files from one hard drive to another. I will just list down the reasons :

1. Deducting the transfer time for compressors that use a temporary folder will reduce the speed advantage of compressors that write directly to the archive. That wouldn't be fair or accurate since in the real world, the former compressors will still take time to move the archive from the temporary folder to the actual folder.

2. Timing how long it takes to copy the fileset from one hard drive to another isn't even accurate in the first place since the compressors would not be copying the UNCOMPRESSED fileset but the compressed fileset which would be smaller.

3. Even if we become truly purist (and crazy!) and deduct the time it takes to copy every compressed fileset from one hard drive to another, we CANNOT account for hard drive caching which will affect the results.

In short, it is not only inaccurate to do what you are suggesting, it is also unfair to compressors that write directly to the archive. They have a speed advantage in that sense and it isn't right to mess with the results just to deprive them of that advantage.

[Olle P]

Seems like we're still thinking past each other...

Originally Posted by Adrian Wong

Actually, for both methods, the CPU does not actually interfere with the data transfer.

Not as such, but it does interfere with the data being transfered and the time between "read" and "write".
The CPU does the optimisation calculation that figures out exactly what to write into the compressed archive. This calculation adds time between "read" of the original file and "write" to the archive.
Without that "interference" it would be a straight copy.

I'm less up to date with exactly how much the CPU is involved with the actual HDD and data bus I/O control.

Originally Posted by Adrian Wong

... moving the archive from the temporary folder to the actual folder takes only seconds, ...

Depends on file size, bus and media speeds, doesn't it?

Originally Posted by Adrian Wong

1. Deducting the transfer time for compressors that use a temporary folder will reduce the speed advantage of compressors that write directly to the archive.

I've not suggested to deduct the actual tranfer time used by each method, but the total time needed for making one straight copy of the original data.
Just call that compression method "Copy" and give it a compression rating of exactly 0.0% for all file types.

Originally Posted by Adrian Wong

2. Timing how long it takes to copy the fileset from one hard drive to another isn't even accurate in the first place since the compressors would not be copying the UNCOMPRESSED fileset but the compressed fileset which would be smaller.

Doing the compression requires CPU time, and one of the key issues here is to compare how long it takes, from start to finish, to create a compressed archive as opposed to creating an uncompressed file/folder.

Originally Posted by Adrian Wong

3. Even if we become truly purist ... we CANNOT account for hard drive caching which will affect the results.

That's where large RAM and small originals come into play. Compressing a smaller amount of data can be done without HDD caching.

Originally Posted by Adrian Wong

In short, it is not only inaccurate to do what you are suggesting, it is also unfair to compressors that write directly to the archive. They have a speed advantage in that sense and it isn't right to mess with the results just to deprive them of that advantage.

As I've pointed out above, this statement is based on a misinterpretation of my suggestion.
Adding the straight copy as just another compression method in the comparison will suffice.

To me the key issue when deciding what compression method to use (if any) is why to do it.
There are a couple of possibilities:

1) I have some data that I want to have accessible in one location on my HDD.
Then a single archive file is convenient, and any compression is fairly irrelevant. A straight copy into one folder will do just fine as well. A single file will use less space on the drive because it fills up all clusters used but one.

2) I'm archiving files for possible future use (for example a back-up copy), and don't want the stored data to use up too much space.
Then I wan't a fairly efficient compression that may take some time to perform, but not hours.

3) I'm going to store some defined amount of data on a media that isn't quite that large. (Like 1GB raw data onto one 800MB CD-R.)
Then any compressor that provide a sufficient amount of compression in a timely manner will do.

4) I have some data that needs to be transfered through a slow channel with limited bandwidth ASAP.
Depending on the amount of data involved I need to optimise the combination of extra time needed to do the compression versus the reduction in transfer time gained by the reduced file size.

5) I've got some sizeable data (like a movie or program) that I've created, and want to publish it on a website for others to download. Minimizing the file size is crucial to cut download times and bandwidth use.
Then the most powerful compressor is a very good choice, even if it takes hours to create the compressed file. There needs to be an easy accessable and free decompressor publicly available though.

I hope this clears things up a bit.

Cheers
Olle