Proprietary Formats: Compression Rate, Size, And Duration
First, we looked at the proprietary formats supported by each of the four solutions. Remember that the total size of the source files is 650MB. We always used default compression, as well as the best compression settings we could find in the tools’ GUIs.
Looking at the resulting file size, we get quite impressive savings. Clearly, the LZMA compression and FreeArc’s ARC seem to work best, giving you between 350MB and 356MB results.
The compression ratio in our diagram tells you just how much smaller the target archives are. The range starts at 39.5% smaller and ends at 46.2 percent.
This diagram tells you the opposite. What’s the target file size in relation to the source data?
The time required for compression is also important. While WinZip actually took between three and a half and four minutes, 7-Zip with LZMA2 and default compression only took 45 seconds for the same workload. Clearly, processing time differs significantly. On the summary page, we multiply the processing time and end file size to reach an overall index that takes both factors into account.
why tomshardware remove the Print Option from all the Articles?
really too bad
Do people still use WinZip??
Also, with every new WinZip version what else they change apart from some graphics on the GUI?? I've realized "Zip" was a bad choice since the LHA/ARJ days...
7-zip also supports multi-volume archives (at least the stable 4.65). It's an option called "volume size", and you automatically get a multi-volume archive.
I disagree with the way weighting was assigned, as simply a product of processing time and file size. I have a tool that would win: gnu tar. It does not do any compression, and should be able to "compress" the 650 MB workload into 650 MB in whatever time it takes to read/write the data. An overall "score" should factor in how you might use the compressed data.
In my opinion, the tradeoff between speed and compression depends on what you want to do with the data. Assuming you have a 56kbps modem connection, you'd spend the extra hour compressing if it saved 25 MB. However, if you have a 1 Mbps line, the same file savings of 25 MB would only be worth 4 minutes of your time. In the case of storing to (fast) local backup, the shift should be even more toward faster compression.
why tomshardware remove the Print Option from all the Articles?really too bad
They did not. Look for the printer icon near the top of the "Comments" header.
jakobbg how smart u are , this print only the current Page(i think u can do it from your browser! right Mr. Smart), what i meant is gone the Print article Option, OK take some omega3 (very good for brain)
Using an SSD to to archival/compression tests? Most of us use slow, "green", rotating platters for that. Any speed advantage 7zip has over winrar or winzip will disappear when you switch your expensive and puny-sized SSD with a cheap, reliable, multi-TB mechanical HDD.
What is left is OS/application integration/adoption and there winzip is best. Winrar comes in a well deserved second place, for some of it's more interesting functions, that the others do not offer (like deep recursion into a given folder and auto decompression of all found archives, no matter the packaging method).
Very useful article, Thanks.
So you tested a beta version of WinRAR even though the final is out for some time now... Good job!
My guess is that they removed the printer friendly version because anyone was able to read an article before it was published (and complete).
WinACE used to be a very good piece of software, and quite popular too. Why is isn't included in this review?
WinACE used to be a very good piece of software, and quite popular too. Why is isn't included in this review?
Because it was probably last updated around February 2008?
A point to consider when talking about multi-thread operation:
When running a compression with 7z on a dual-core machine, wouldn't using both cores cause the entire machine to chug and be unresponsive? I find it more useful to just let it (and other software) use a single thread - it may take longer, but I can still use the computer all the while.
It makes me glad that I was a moderately early adopter of 7-zip. Although probably the nicest thing about it is that it will correctly decompress several things that aren't "supported".
The review date is March 10th, and WinRAR 3.92 beta 1 was used in the review even though the final version was released enough time before the the review date.
"Last updated: 15 February 2010
* WinRAR and RAR 3.92 release"
Strange...
The review was originally published a month ago on the German THG. So there's nothing "suspicious" about using a beta of WinRAR, because the final did not exist when the testing was done.
The thing I hate about 7-zip is the crappy icons, but everything else is dandy.
The article is incorrect that WinRAR is the only one that supports multi-volume archives. 7-Zip has supported this for several years now (since late 2005, iirc).
I've been hammering Corel whenever I talk to a company rep about multi-threading, all the way back to around 2001, and Corel owns Winzip now. I am a Corel user, have been since 1993, I'm a winzip user, have been since PKZip 2.5x. I hope Corel gets with the whole multi-threaded world, even though it is more complicated to program, because we all know future performance and efficiency is not through clock speeds but through parallelism.
7-zip also has the option of integrating with the OS via contextual menus, but for some reason the devs do not do this by default on installation.
You have to open the program options and enable the contextual menus, which improve 7-zip's usability significantly.