Compression Comparison Guide

[firehorse]

Great job on the review.

Looking forward to the results on the other settings.

[Adrian Wong]

Originally Posted by Olle P

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 don't get what exactly you are trying to imply here. The CPU needs to "calculate" where it needs to write to the compressed archive?? Where did you read about that??

In any case, I would agree that the two methods would have different results. Writing directly to the final file would be faster than writing to a temp file and then copying it to the final folder.

But that doesn't change the fact that the test results should still NOT be manipulated in any way. Even if you want to find out the pure compression speed of the different data compressors, deducting the copy time from the results will still result in skewed data. It will slant the results in favour of data compressors that write directly to the final file.

Originally Posted by Olle P

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

Exactly why manipulating the results would make them totally inaccurate and the comparison unfair.

Originally Posted by Olle P

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.
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.

Oh, I see! Now that makes some sense. LOL!

Okay, so you just wanted to see how long it takes to JUST copy the UNcompressed files from one test hard drive to the other?

Yeah, that would make for an interesting comparison.

Originally Posted by Olle P

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

Err.. Actually, hard drive caching always affects performance. That's why we cannot just manipulate the data. It's not like MS-DOS where you can turn off hard drive caching.

Originally Posted by Olle P

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

Oh yeah, that definitely cleared up the confusion. LOL!! Looks like it was all one big messed-up discussion.

I think I get what you mean now. You only want me to add a straight copy result to provide an additional basis for comparison, right?

Yes, that would make for an interesting comparison, but readers should be informed NOT to deduct it from the current results to "obtain" pure compression speeds. That would be totally inaccurate for the reasons already explained.

[Adrian Wong]

Originally Posted by firehorse

Great job on the review.

Looking forward to the results on the other settings.

Thanks. Sorry about the long time I'm taking. Been super busy, plus the big CNY holidays are coming soon.

[Olle P]

Originally Posted by Adrian Wong

I don't get what exactly you are trying to imply here. The CPU needs to "calculate" where it needs to write to the compressed archive?

Not "where" but "what" to write.
The compression is a manipulation (altering) of the original data, and the CPU is used to figure out exactly what the new file should "look" like.

Originally Posted by Adrian Wong

... hard drive caching always affects performance. That's why we cannot just manipulate the data. It's not like MS-DOS where you can turn off hard drive caching.

Yes you can (System properties / Advanced => Performance / Settings => Advanced / Virtual memory / Change => "No swap file" / Activate), but shouldn't be done. That's why I make a point of compressing relatively small amounts of data, so that the swap file doesn't come into play.

Originally Posted by Adrian Wong

You only want me to add a straight copy result to provide an additional basis for comparison, right?

Originally Posted by Adrian Wong

... readers should be informed NOT to deduct it from the current results to "obtain" pure compression speeds.

Pure compression speed is pretty irrelevant to me, the total time used/gained/lost vs compression rating is far more important.

Cheers
Olle

[Adrian Wong]

Originally Posted by Olle P

Not "where" but "what" to write.
The compression is a manipulation (altering) of the original data, and the CPU is used to figure out exactly what the new file should "look" like.

Err.. The compressors certainly use the processor to do that. In fact, as mentioned earlier, I intentionally used a slower processor to reduce the effect of the writing data on the actual compression time.

Originally Posted by Olle P

Yes you can (System properties / Advanced => Performance / Settings => Advanced / Virtual memory / Change => "No swap file" / Activate), but shouldn't be done. That's why I make a point of compressing relatively small amounts of data, so that the swap file doesn't come into play.

Huh?? Swap file? We are talking about hard drive CACHING, remember?

The paging file or swap file is for virtual memory. It has no bearing whatsoever on hard drive caching.

Originally Posted by Olle P

Pure compression speed is pretty irrelevant to me, the total time used/gained/lost vs compression rating is far more important.

The compression speed is a reflection of the actual compression times. I can probably show you the compression times but it will just be a reverse of the compression speed charts.

Incidentally, talking about showing the pure copy time of the files from one hard drive to another...

While I think it's an interesting comparison, when I had the time to actually think about it, it's a comparison of limited use and one that very few people would be interested in.

The only reason why we would want to compare pure copy times with compression times would be if we are used to copying data from one location to another and wanted to see how much longer it would take to compress and move it to that final location.

Other than that.. what possible use could pure copy results have? I think it will only confuse the other readers who will be wondering why we are comparing the time it takes to copy the files from one location to another with the time it takes to compress those files.

In many cases, this does not serve as a valid baseline as many people just compress the files in the same hard drive, and delete the originals afterwards. The pure copy speed will therefore make no sense at all.

[Dashken]

The article has just been updated!

Data compression are now part of everyday life. We compress everything from pictures and video clips to documents and more. But just which data compressor is suitable? There are so many of them!

This guide will help you choose the best data compressor for the job you have on hand. Read on and find out!

The update is:-

- Part 1 of the new compression comparison guide released.

Link : Compression Comparison Guide Rev. 2.0 Part 1!

[Dashken]

Data compression are now part of everyday life. We compress everything from pictures and video clips to documents and more. But just which data compressor is suitable? There are so many of them.

This guide will help you choose the best data compressor for the job you have on hand. We have just added Normal Compression benchmarks to the Fast Compression results we have posted earlier. Read on and find out.

The update is:-

- Part 2 of the new compression comparison guide released.

Link : Compression Comparison Guide Rev. 2.0 Parts 1 & 2

[wimh]

Another good page is the Practical Compressor Test, which plots the relation between compression ratio and speed for a number of compression algorithms, this gives another interesting look at the same data.

[asbjornu]

In the table on page 2 of the article, "Best Compression" is listed as TBA at the moment of this writing. Does this mean it isn't tested or does it mean it's just not written down? Because if it isn't tested, then the test is pretty much useless. Not testing e.g. 7-Zip on "Ultra" compression doesn't explore its capabilities at all. The default level is a compromise between speed and compression level and can't be used for any measurement imo. At least not considering the range of different values on the default compression in the different archivers.

[Adrian Wong]

Originally Posted by asbjornu

In the table on page 2 of the article, "Best Compression" is listed as TBA at the moment of this writing. Does this mean it isn't tested or does it mean it's just not written down? Because if it isn't tested, then the test is pretty much useless. Not testing e.g. 7-Zip on "Ultra" compression doesn't explore its capabilities at all. The default level is a compromise between speed and compression level and can't be used for any measurement imo. At least not considering the range of different values on the default compression in the different archivers.

Hello asbjornu,

We are releasing it in stages because it takes a LONG time to test these compressors using so many filesets. We are releasing the results as we obtain them.

Needless to say, the next part to be posted will concentrate on their maximum compression. And then we will compare all data compressors at different settings and add new data compressors.

This is an on-going effort that has just started, and will continue over time.

As for the default level, we are testing that for a very simple reason. Many users are not bothered or not comfortable changing the compression settings. So, it makes sense to test the default settings for those who like to use the data compressors as they come.