Hello Steve, Thank you for writing in to us about the guide. Indeed, we intend to not only finish this part but expand it over time with more compressors and perhaps even other types of tests. 1. Right now, I chose not to handle inflation (or decompression) speeds yet as it requires an equivalent amount of data to process. I'm not sure if our readers would take too kindly to a guide that runs into 60-70 pages. Yeah, it would be interesting to see just how fast they decompress. But so far, most of our readers seem to be more interested in compression than decompression. It's understandable though. Compression takes far, far longer than decompression. 2. That's a good idea actually. In fact, we used a somewhat similar method to test lens focus time in our tests of camera lenses. However, it is not a good idea to use CPU time as a measure of the total compression time, as some compressors do not write directly to the archive. Instead, they write to a temporary folder and then write the final archive to the destination folder at the end. During this time, the CPU time will be low, but the compressors will still be active. To accurately measure the time it takes for a compressor to completely finish processing the fileset, I chose to record the time manually. Although this introduces some error, this allows us to account for the time some compressors take to finish writing the archive. I've attempted to keep the error low by using large filesets of at least 200MB in size. This forces the tests to run long enough for measurement errors of less than a second not to matter much in the final results. Also, we kept the error at least consistent for all compressors by using the same tester for each and every test... ME. 3. Yes, testing different formats using the same compressor (WinRAR compressing ZIP) would be something we would be interested in looking at in future updates. 4. Hmm.. That is always possible, although it would introduce some controversy. Which website would be chosen for the task? Tech ARP? Wikipedia? Different websites have different mixtures of highly compressible files like HTMLs and poor compressible files like GIFs and PNGs. I fear that testing mixtures like this would not accurately represent real world results, except for websites that use about the same mixture of data (both size and types). That's why I chose to stick to a single filetype... or at least the same type of files. Do watch out for the next update. I hope to complete the tests and have the results out by this weekend. Unfortunately, these tests take a lot of time even with a new Core 2 Duo testbed!
We have just added Maximum Compression results to the guide. 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:- Link : Compression Comparison Guide Rev. 2.0 Parts 1, 2 & 3
Compression Comparison Guide Rev. 2.0 This update completes the Compression Comparison Guide. Finally, 5 years after we posted the first version, we have a new revision of the guide. This new Compression Comparison Guide takes a look at 11 common data compressors and their performance in 8 different filesets at 3 different compression settings. The result is a detailed but easily accessible look at these data compressors and how they perform with a wide variety of filetypes. The results of this guide will surprise you. Data compressors that we may have given up as old-fashioned or outdated are actually still highly competitive. Even filesets that you thought was difficult to compress can be relatively easy to tackle. Read on and find out. We hope this guide will help you choose the best data compressor and settings for your compression tasks. Link : Compression Comparison Guide Rev. 2.0
Efficiency is mis-calculated I'd like to argue that the efficiency calculation (compression over time-to-compress) is inadequate for many if not most purposes. Consider the following real-world scenarios (as opposed to simply picking one's favourite utility) Archiving Packaging Transmission Archiving has a very simple purpose: saving space. I think we can all agree that time doesn't really matter here at all. We're talking about large amounts of data being compressed to save space. Instantaneous minimal compression is totally useless. Packaging has a slightly more complicated purpose: safety/security. Here, compression doesn't matter at all. It's all about time. Transmission is the objective that benefits both from the amount of compression, and the time required to compress. That is the efficiency mentioned in the article. And it is totally useless for most transmissions these days. That kind of efficiency is good for space-craft sending data from distant planets. But it's useless for sending web pages to a browser. I'm arguing that decompression time is just as important. I would like to see the efficiency recalculated to include the time required to decompress the stream. Since every real-world scenario is going to have components of all three objectives, I argue that the decompression time will be relevant to most real-world scenarios.
Actually, as mentioned in the article, efficiency is not to be the one criteria to decide on any compressor. An efficient compressor is always desirable, but other factors are equally, if not more important. For example, WinZip might be more efficient than WinRAR. But I would still prefer to use WinRAR because of its support for the RAR format (pretty popular these days) and its better compression performance. LOL! There's no need to argue. I don't think anyone here has ever said that decompression speed is not important. As mentioned ABOVE, I personally think it would be interesting to check out the decompression speed as well. But all these tests take an enormous amount of time. We have to give priority to compression, over decompression. We will do our best to include decompression results soon, but do understand that all this takes time. There's also the issue of different compression SETTINGS affecting the decompression speed, even for the same compressor. It's not only about the archive size (which will differ from setting to setting) but also the method of packing. Needless to say, the task of examining decompression speed will be as complicated and time-consuming as examining compression speed.
I would like to see UHarc compared as well. http://en.wikipedia.org/wiki/UHarc I think UHarc is favoured by the undeground for compressing multimedia.
Thanks for a nicely detailed comparison of compression software! I have one query about the test setup... In your Test Settings section you mention that 7-zip had multi-threading enabled. You don't mention the multi-threading option for WinRAR. Was multi-threading support enabled in WinRAR for these tests?
Hi msl, thanks for your kind words. I only mentioned the settings as available to the user. So, the lack of mention does not mean multi-threading is not active. But the answer to your question is yes. Multi-threading support was enabled in WinRAR. Incidentally, there is no need to set anything to enable multi-threading in WinRAR. It supports multi-threading by default. You can disable it though.
I was particularly curious since I revisited 7-zip recently and compared some compression times with 7-zip 4.42 and WinRAR 3.70 on my Core 2 Duo E6600 system. With both archivers at default settings ('Normal' compression mode for WinRAR rather than the 'Fastest' mode your comparison uses) and multi-threading enabled, I found WinRAR to generally offer similar or faster speeds than 7-zip while 7-zip generally produced similar or slightly better compression. There certainly wasn't the huge difference in speed shown up by your testing. Perhaps there are some big performance gains in recent 7-zip betas...?
Wow, it seems like the recent betas of 7-zip really have made huge steps forwards in performance! I gave 7-zip 4.51 beta a quick try and, although it uses quite a bit more memory than WinRAR, it seems significantly faster while still maintaining its compression rates.
I'll be retesting the entire suite again, because we have an updated testbed. May also include decompression times. But it will be a really massive project.
It may be worth considering solid and non-solid archives when you re-test. I notice that you used WinRAR in "solid" mode for all of your tests, which is not the default. Solid can have compression advantages (depending on the data set) but non-solid has advantages in accessibility of individual files within an archive. In terms of performance, WinRAR seems to be significantly faster creating non-solid rather than solid archives. 7-zip on the other hand creates solid archives by default and seems to be generally slower when creating non-solid archives. I think multi-threading also shakes the results up a bit. Some archivers/compressors seem to do a better job than others of exploiting multi-threading. If you want to save some time on the testing, you could cut down on the tests on fundamentally incompressible data (i.e. data that is already in a highly compressed state). This only really seems interesting to me to compare speed for backup/archiving purposes and compression ratios are irrelevant. Using anything other than the fastest available settings is probably a waste in these cases.
Good point. Well, if I test solid archives, I would test for all. If not, we can retest without using solid archives. But it would be too much work to test for both. Multi-threading support is always enabled. Yeah, still thinking on the poorly compressible files. Originally added them to show everyone just how poorly compressible they are. May replace them with other files. Then again, there are many who still compress video clips in RAR or ZIP for sharing online.
New version of Stuffit should "kick butt" on this test set I'm the VP of advanced technology at Smith Micro - I'd love to see the test results updated to include our latest version. - Darryl
Hi Darryl, I've been planning to redo it soon but it will be a really massive effort - new testbed, new file types, new tests (compression, decompression), etc.
2012 ... nothing has changed in FIVE years ?? Everyone here is avoiding my favorite freeware. It works best & easily on most other freeware I use: W7 & *buntu. My Intel I7, with 8 threads, 4 cores, .... 7-Zip 9.20 (2010-11-18 7-Zip 9.25 alpha 2011-09-16 7-Zip 9.26 2012-04-01 Next version is expected to be released in April 2012 Sourced now, from 7-zip DOT org quote: The main features of 7-Zip High compression ratio in 7z format with LZMA and LZMA2 compression Supported formats: Packing / unpacking: 7z, XZ, BZIP2, GZIP, TAR, ZIP and WIM Unpacking only: ARJ, CAB, CHM, CPIO, CramFS, DEB, DMG, FAT, HFS, ISO, LZH, LZMA, MBR, MSI, NSIS, NTFS, RAR, RPM, SquashFS, UDF, VHD, WIM, XAR and Z. For ZIP and GZIP formats, 7-Zip provides a compression ratio that is 2-10 % better than the ratio provided by PKZip and WinZip Strong AES-256 encryption in 7z and ZIP formats Self-extracting capability for 7z format Integration with Windows Shell Powerful File Manager Powerful command line version Plugin for FAR Manager Localizations for 79 languages endquote:
