Compression Performance: 7-Zip, MagicRAR, WinRAR, WinZip

Page 3 - Seeking answers? Join the Tom's Hardware community: where nearly two million members share solutions and discuss the latest tech.
Status
Not open for further replies.

andrej_valand

Distinguished
Jul 14, 2009
4
0
18,510
I also tried the 7-Zip when i saw the review in hope it would speed up my backup times. To be only quite disappointed. My results reflect ElDani measurements.

Test was done with 1394files 3120MB total size. File types range from documents, pictures, programs, html files, short clips and pdf files.

WinRAR: File size 2450MB compression time 3:21 minutes
7Zip:Filessize 2320MB compression time 8:12 minutes

Both times default settings ware used. What are we missing to see so bad results? I can get smaller archive but compresion times are quite bad even worse with 1024mb dictionary size I also tried a small dictionary of 1MB same slow result..
 

EasterEEL1

Distinguished
Jan 31, 2004
6
0
18,510
I'm confused 7-zip 9.28b does not seem to be a versions available for download, it's not even mentioned in the version history! Also what was tested the 32bit or the 64bit ??

On the 7-zip downloads page the options are:
Latest non beta 7-Zip 9.20 (2010-11-18)
Latest beta 7-Zip 9.22b (2011-04-18)
Latest alpha 7-Zip 9.30A (2012-10-26)

I have use WinRAR and 7-zip 9.20 extensively and they trade blows when it comes to size of file. Yes 7-zip uses hyper threading and Winrar doesn't but it don't add up to much difference in time. I would like to find the 7-zip 9.28b and know what the golden settings used are as at the moment I am very sceptical about the claims made in this article.
 

sLOVEnec

Distinguished
Mar 3, 2004
3
0
18,510
There is only one feature missing to 7zip: the option when unziping/raring/etc multiple compressed files, to wait for other instances of 7zip to finish.
 

mariush

Distinguished
Oct 29, 2008
12
0
18,510
There's two important things missing in this test:

1. Decompression speed

Yes, you may compress the archives on a fast computer but they may have to be distributed to various computers, with various specs.
You may want to trade high compression for fast decompression speed.

This is especially important for example if you design a portable version of your software and pack all your libraries or resources in an single file along your executable.

2. Memory requirements

Some algorithms (like LZMA2, PPmd etc) require relatively large amounts of memory to work, especially at the highest compression values.

WinRAR restricts such algorithms in the current versions to about 128 MB if I remember correctly, but 7zip can use up to 1-2 GB of memory to decompress, not to mention up to 48-64 GB (yes, GB) to compress.. see lzma 2 ultra with large dictionary sizes.

If you're developing some software and want to distribute it to some people, you don't want to make a self extract archive that will crash on computers with only 512-1GB of memory installed (and yes, there are quite a few of them out there)
 

techcurious

Distinguished
Jul 14, 2009
228
0
18,680
Epic FAIL for Toms to review a product version (7-Zip 9.28b) without pointing out that it is not a version that can be downloaded anywhere (not that I have found yet) and without addressing whether or not getting a different version would result in significantly different performance numbers or not! ESPECIALLY after giving that product an Elite Award!
For all we know, the version 9.22 (latest non-Alpha version I could find) which is almost 2 years old will perform nowhere near as a fast as the 9.28beta version that they have managed to get their hands on..
Or... Toms, did you make a massive typo and Editing FAIL? Did you actually test version 9.22beta???
Even the image of the 7-Zip webpage you posted does not reflect any 9.28beta option!

Either way, I was glad I read this article, until I tried to download the latest 7-Zip (I already had 9.20 I downloaded 2 years ago!), and now I am frustrated instead...
 

MaXimus421

Distinguished
Jan 22, 2012
304
0
18,860
Decompression is more important to me personally. Odd that it wasn't shown here. I mean, these apps for for compression AND decompression. And I might be off the mark here, but I would think the decompression feature would be used much more then the compression.
 

ElHarry

Distinguished
Jan 5, 2010
9
0
18,510
[citation][nom]ddpruitt[/nom]... BZIP2 and GZIP ... had to be fast because they had no choice, because you can't waste CPU cycles or tape...[/citation]

input 229861 kB in 645 files in directory "5.0.19"
tar-7z 1 thread 15205 kB 99 seconds
tar-7z 24 threads 31487 kB 17 seconds
tar-7z 40 threads 32604 kB 12 seconds
tar-bzip2 48828 kB 66 seconds
tar-gzip 57307 kB 34 seconds

1 thread
tar -cf - 5.0.19 | 7za a -si -mx=9 -mfb=512 -md=225m -m0=lzma2 5.0.19.tar.7z
24 threads
tar -cf - 5.0.19 | 7za a -si -mx=9 -mfb=512 -md=9m -mmt=24 -m0=lzma2 5.0.19.tar.7z
40 threads
tar -cf - 5.0.19 | 7za a -si -mx=9 -mfb=512 -md=5m -mmt=40 -m0=lzma2 5.0.19.tar.7z

 

MagicRAR

Honorable
Mar 25, 2013
2
0
10,510
Thank you very much for including MagicRAR in your recent article at Tom’s Hardware. This is such a privilege, to see our relatively new product featured in the same article along with long-time industry veterans. Thank you very much for this privilege.

Your article highlights the poor compression speed (although we came second in the maximum compression chart) in MagicRAR. This is unfortunately because our core compression plug-ins are based on 2004 technology. Your article has served to highlight this as a significant shortcoming, and we will be mobilizing our entire development staff to quickly bring our performance in line with the expectations of the new decade. Thank you very much for sharing this strategic, key insight.

After all of your generosity kindness in covering us in your great article, I really don’t want to create more work for you…but unfortunately, there are a few technical inaccuracies in the article which I feel merit an official response. Also, some user comments indicate that they were confused as to why MagicRAR was included in the review – given the utterly poor benchmark scores. I believe the clarifications for the issues I have highlighted below may help justify the inclusion of MagicRAR in your review:

1) On page 1 of your review, you write “The more exotic MagicRAR, which claims to triple Windows’s built-in compression, completes today’s round-up.”

However, it is not made clear that the Windows built-in compression being referred to is not file archiving, but transparent NTFS (full-disk) compression. It is also never mentioned anywhere in the review that MagicRAR is the only utility available for Windows today, which is capable of doing this on Windows.

2) On page 3 of your review, you write “…doesn’t have its own compression format, or make use of more than one processor core.”

This is false on multiple counts:

a) MagicRAR’s full disk compression utility (that #1 above refers to) can use up to double the CPU cores (including HT cores) available on a system; or even any arbitrary number of cores when MagicRAR’s NTFS compression is being invoked from the command line. I had previously sent you these command line parameters in an email to you dated 3/10/2013. Please see screenshot at www.magicrar.com/images/ScreenShort05.jpg as proof.

b) Additionally, MagicRAR’s 7zip format compressor is able to use two CPU cores when compressing.

c) Finally, even where the compression/extraction algorithms themselves are single-core (due to the dated plug-ins which haven’t been refreshed for a while), MagicRAR can process multiple compression/extraction tasks simultaneously when the “parallel” option is checked. This is a way of processing more than one archive at the same time on the same computer; thus “artificially” using multiple-cores. It may be thought of as a sort of “poor man’s parallelism” since all but the 7zip MagicRAR plug-in are not internally multi-core yet. Please see screenshot at www.magicrar.com/images/ScreenShort04.jpg for proof of this “poor man’s parallelism” approach.

3) Again on page 3 of your review, you write “MagicRAR comes with its own file manager…”

While this is true, this is not the magic of MagicRAR. MagicRAR is the only utility which features a shell namespace extension (screenshot at www.magicrar.com/images/ScreenShort01.jpg) that mounts archives of all types as ordinary folders in Windows Explorer; and transparently compresses/extracts files inside archives when copy-paste, drag-drop, double-click, and any number of other typical Explorer commands are used. This is why we have called MagicRAR, MagicRAR.

4) Again on page 3, you write “According to its developer, this application is supposed to yield especially good performance on SSDs. However, our benchmarks don’t bear this out. In fact, we found the opposite to be true. No other tool takes as long to compress files on SSDs, with only ZIP performance rating as acceptable.”

MagicRAR’s claim of being SSD optimized applies to the multi-core full disk compression utility (as described in #1 and #2a above), and MagicRAR’s parallel mode shell extensions/”poor man’s parallelism” (as described in #2c above), all of which perform superbly on SSDs. On non-SSD hardware, using a large number of cores in either scenario would cause significant degradation in performance, of course.

5) On page 11 of your review, you write “MagicRAR is single-threaded, and consequently gets no benefit with Hyper-Threading turned on. In fact, it ends up being somewhat slower with the feature enabled.”

With the 7zip algorithm, MagicRAR is actually multi-threaded. Unfortunately, this is the only algorithm that it is multi-threaded for; and it only uses a maximum of two cores. This is again because of the dated plug-ins that are included with MagicRAR, and something we will be immediately starting to work on. However, per #2c above, you should have seen dual core usage with the 7zip output type in MagicRAR. I am wondering if the compression profile got corrupted somehow?

6) On the last page of your review, you write “At least as a compression tool (MagicRAR actually includes a number of different utilities), we don't think this one stands apart.”

Here, you are dropping a hint of MagicRAR’s other benefits, but not discussing any of them. I believe this might explain why some users are perplexed that MagicRAR was included in the review at all. I realize you have focused on performance exclusively in your review; so it probably makes little sense to discuss either MagicRAR’s shell namespace extensions, or MagicRAR’s full disk NTFS compressor tool. I can only thank you for having included us at all, and I will be following up as soon as we have addressed the performance issues.

Maybe it would be great if you could cover MagicRAR’s full disk NTFS compressor in a separate study. I know there’s no archive utilities you could compare it to, because it is unique. Same for the shell namespace extension. But here’s some ideas for the full disk NTFS compressor:

a) It would be interesting to measure how well the NTFS compressor runs in converting SSD drives, under different core/thread settings for different models of SSDs.
b) You could also check whether our claim of “three times better than Windows compression” stands up to the test on real-world, production systems.
c) Now that it has command line support, you could even use it as an automated benchmark of sorts for measuring SSD performance itself.

Imagine hammering an SSD with any random number of reads and writes, over and over again – just by enabling and disabling NTFS compression.

Once again, many thanks for having featured us in this performance review, despite us having come out as the worst performer!

I truly hope my feedback above is helpful for your users.

- Simon King.
 

MagicRAR

Honorable
Mar 25, 2013
2
0
10,510
Thank you very much for including MagicRAR in your recent article at Tom’s Hardware. This is such a privilege, to see our relatively new product featured in the same article along with long-time industry veterans. Thank you very much for this privilege.

Your article highlights the poor compression speed (although we came second in the maximum compression chart) in MagicRAR. This is unfortunately because our core compression plug-ins are based on 2004 technology. Your article has served to highlight this as a significant shortcoming, and we will be mobilizing our entire development staff to quickly bring our performance in line with the expectations of the new decade. Thank you very much for sharing this strategic, key insight.

After all of your generosity kindness in covering us in your great article, I really don’t want to create more work for you…but unfortunately, there are a few technical inaccuracies in the article which I feel merit an official response. Also, some user comments indicate that they were confused as to why MagicRAR was included in the review – given the utterly poor benchmark scores. I believe the clarifications for the issues I have highlighted below may help justify the inclusion of MagicRAR in your review:

1) On page 1 of your review, you write “The more exotic MagicRAR, which claims to triple Windows’s built-in compression, completes today’s round-up.”

However, it is not made clear that the Windows built-in compression being referred to is not file archiving, but transparent NTFS (full-disk) compression. It is also never mentioned anywhere in the review that MagicRAR is the only utility available for Windows today, which is capable of doing this on Windows.

2) On page 3 of your review, you write “…doesn’t have its own compression format, or make use of more than one processor core.”

This is false on multiple counts:

a) MagicRAR’s full disk compression utility (that #1 above refers to) can use up to double the CPU cores (including HT cores) available on a system; or even any arbitrary number of cores when MagicRAR’s NTFS compression is being invoked from the command line. I had previously sent you these command line parameters in an email to you dated 3/10/2013. Please see screenshot at www.magicrar.com/images/ScreenShort05.jpg as proof.

b) Additionally, MagicRAR’s 7zip format compressor is able to use two CPU cores when compressing.

c) Finally, even where the compression/extraction algorithms themselves are single-core (due to the dated plug-ins which haven’t been refreshed for a while), MagicRAR can process multiple compression/extraction tasks simultaneously when the “parallel” option is checked. This is a way of processing more than one archive at the same time on the same computer; thus “artificially” using multiple-cores. It may be thought of as a sort of “poor man’s parallelism” since all but the 7zip MagicRAR plug-in are not internally multi-core yet. Please see screenshot at www.magicrar.com/images/ScreenShort04.jpg for proof of this “poor man’s parallelism” approach.

3) Again on page 3 of your review, you write “MagicRAR comes with its own file manager…”

While this is true, this is not the magic of MagicRAR. MagicRAR is the only utility which features a shell namespace extension (screenshot at www.magicrar.com/images/ScreenShort01.jpg) that mounts archives of all types as ordinary folders in Windows Explorer; and transparently compresses/extracts files inside archives when copy-paste, drag-drop, double-click, and any number of other typical Explorer commands are used. This is why we have called MagicRAR, MagicRAR.

4) Again on page 3, you write “According to its developer, this application is supposed to yield especially good performance on SSDs. However, our benchmarks don’t bear this out. In fact, we found the opposite to be true. No other tool takes as long to compress files on SSDs, with only ZIP performance rating as acceptable.”

MagicRAR’s claim of being SSD optimized applies to the multi-core full disk compression utility (as described in #1 and #2a above), and MagicRAR’s parallel mode shell extensions/”poor man’s parallelism” (as described in #2c above), all of which perform superbly on SSDs. On non-SSD hardware, using a large number of cores in either scenario would cause significant degradation in performance, of course.

5) On page 11 of your review, you write “MagicRAR is single-threaded, and consequently gets no benefit with Hyper-Threading turned on. In fact, it ends up being somewhat slower with the feature enabled.”

With the 7zip algorithm, MagicRAR is actually multi-threaded. Unfortunately, this is the only algorithm that it is multi-threaded for; and it only uses a maximum of two cores. This is again because of the dated plug-ins that are included with MagicRAR, and something we will be immediately starting to work on. However, per #2c above, you should have seen dual core usage with the 7zip output type in MagicRAR. I am wondering if the compression profile got corrupted somehow?

6) On the last page of your review, you write “At least as a compression tool (MagicRAR actually includes a number of different utilities), we don't think this one stands apart.”

Here, you are dropping a hint of MagicRAR’s other benefits, but not discussing any of them. I believe this might explain why some users are perplexed that MagicRAR was included in the review at all. I realize you have focused on performance exclusively in your review; so it probably makes little sense to discuss either MagicRAR’s shell namespace extensions, or MagicRAR’s full disk NTFS compressor tool. I can only thank you for having included us at all, and I will be following up as soon as we have addressed the performance issues.

Maybe it would be great if you could cover MagicRAR’s full disk NTFS compressor in a separate study. I know there’s no archive utilities you could compare it to, because it is unique. Same for the shell namespace extension. But here’s some ideas for the full disk NTFS compressor:

a) It would be interesting to measure how well the NTFS compressor runs in converting SSD drives, under different core/thread settings for different models of SSDs.
b) You could also check whether our claim of “three times better than Windows compression” stands up to the test on real-world, production systems.
c) Now that it has command line support, you could even use it as an automated benchmark of sorts for measuring SSD performance itself.

Imagine hammering an SSD with any random number of reads and writes, over and over again – just by enabling and disabling NTFS compression.

Once again, many thanks for having featured us in this performance review, despite us having come out as the worst performer!

I truly hope my feedback above is helpful for your users.

- Simon King.
 

PlanesFly

Distinguished
Mar 28, 2013
8
0
18,510
I just got done with alot of comparisons with 7zip vs Winzip 15.5 vs. Winzip 17...in every compression test I can do Winzip is considerably faster than 7zip.

Folder containing 713 files totaling 717MB files ranging from a few KB to 150MB.

Best of 3 runs (i7-3840QM CPU 4c/8t 2.8ghz 3.8ghz turbo) 16GB DDR3-1600, dell precision workstation) Win7 64bit
7zip: 24seconds
winzip 17: 16.9 seconds
 

Sergiu Zaharia

Honorable
Mar 28, 2013
1
0
10,510
[citation][nom]mayankleoboy1[/nom]7ZIP is even more impressive when you consider that the LZMA format was designed by one single person. And then the program 7ZIP was also coded by that single person only.Maybe contribute a few dollars to Igor Pavlov , the creator of 7Zip ?[/citation]

Agree, just got a beer to Igor
 

manynames

Honorable
Mar 28, 2013
1
0
10,510
Nice article but it is unfortunate that your 'dark horse' program was a whipping boy commercial program like MagicRAR. I'd love to see the addition of FreeArc (http://freearc.org/), which is mature, handles many more formats and is faster than the options you tested.
 

mrpijey

Distinguished
Sep 8, 2009
89
0
18,630
Unfortunately 7z lacks many advanced options that WinRAR supports, such as recovery data (to prevent bitrot errors), archive comments (to tag archives with info) and such. Which makes it useless for my needs since it's cumbersome to have external parity data or text files as comment files. So until 7z gets there features 7z will not be an option for me.
 

RobAC

Honorable
Mar 31, 2013
31
0
10,530
I still have fond memories of older pkzip and lharc and other compression utils. Always messing with them to see which was better.

The funny thing is I have two Winzip keys that I got because of purchases of Corel products and I never use them. 7Zip came along and I have never bothered with anything else. It's not perfect- but good enough for the limited amount of crunched files I access nowadays.

Current huge capacity HDs have gotten me out of the habit of being anal about every byte saved on my system.
 

Neomien

Honorable
Mar 31, 2013
1
0
10,510
I'd like to see these results comparing with FreeArc's. Many tests are specialized in some way, there is very few widely accepted "proof"-test. Some, like , , all showed us that FreeArc is 2-3x faster then 7-zip or WinRar or WinAce with the same compression ratio, if we are not going beyond "ultra" settings. (See FreeArc "normal" mode vs. 7-zip LZMA2 ultra vs. WinRAR ultra .)
Consideringing that it is one of the most efficient non-specialized compressor, it supports a lot of format, integrate into explorer's menu, has many encrypting options, supports commenting and whats really good: recovery records, it should be the most advertised compressor...
Just that few things whats missing still annoying a bit, if the developer can fix those (multi-volume, file attributes), we will be happier.
 

chronoreverse

Honorable
Apr 2, 2013
1
0
10,510
@ElDani

It looks like your files are text heavy types (being html, js, php and cgi) for which 7-Zip has the PPMd mode for.

Try that out and see what compression ratios you're getting.
 

ElDani

Honorable
Mar 19, 2013
7
1
10,515
@ chronoreverse : Thanks for your reply. The PPMd compression algorithm was already mentioned earlier on page one of this thread and I did test it with my files. Here's a recap of the best WinRAR settings versus these 7-Zip settings for plain-text files:

WinRAR, best compression, solid archive, lock archive, 1024 KB dictionary size = 125.38 MB - 2:06 minutes
7-Zip, PPMd, solid block, 1024 MB dictionary, word size 32 = 120.05 MB - 3:07 minutes

While the archive is smaller by 4.25 percent, the compression takes almost half again as long.
 

ShouldntHave

Distinguished
Aug 31, 2009
44
0
18,530
I dispute the winner.

This article is superficial and thus novice-oriented. I guess to be fair, it's called "Compression Performance" and not "Best compression software", but then again the fact that u trot out that award at the end definitely implies "'Best'-as-in-best-all-around". Folks, there's more to performance than simple crunching. An extended definition of performance is "getting what you want out of the software", and thus usability can play a significant part in actual real-world "performance". 7zip lacks in this area, compared to a more refined product like WinRAR. (Full disclosure: of course I'm a WinRAR user!)

Among other issues:
- You should not be lauding the fact that WinZip has (useless) social and cloud* features. "feature bloat" this is called, where I come from. (not that I'm in any danger of running winzip any time soon. How can i put this ....... ? Ah, I know! "Microsoft Internet Explorer is literally far more relevant to my life than WinZip.") *P.S. I don't know what "cloud" you're hanging out in, but it seems most of the stuff i run into is RARs anyway.

- You neglect to mention some of the additional features available in WinRAR. (Just compare the command-line switches to those available in WinZip or 7zip -- sry, magicrar doesn't even come up on my radar -- and it should be immediately clear which is the winner in terms of feature-richness.) Two of my favorite and most-used are "delete files after archiving" and "put each file to {sic} separate archive". 7zip is severely lacking in this department. And again, usability equals performance! Yeah, I can achieve these same results by using a script, but I don't want to turn every compression task into a software dev project. Which leads me to my next point.....

Surely 7zip gets big points for being FOSS, and there is always that assurance in the back of one's mind that "if this software doesn't do exactly what I want, I can always mod it", but realistically, I have enough unique development aspirations that it's pretty far-fetched that I'd ever spend the time on something so commoditized and utilitarian as branching my compression software; it's never going to happen. (And now that I think about it, apparently no one else has the spare time to polish up 7-zip's GUI, either [/snark])

Similarly, nor do i want to turn every compression task into a geek-out of trying to find the best dictionary size and all that other hoo-hah. I just want to get this pile of whatever garbage i'm archiving out of my way and get some real work done!

- Your test file batch is simplistic and unrealistic. Do ppl really just compress a whole drive, or a whole bunch of heterogeneous files out of their "my documents" or whatever? In my experience, no. You compress a category of files, such as "documents" or "pictures" or "videos", etc. Only a sloppy user is going to have a folder full of unorganized files and want to archive them all in one go. (So yeah, again, novice-oriented information, i guess.)

- Finally.... Last I checked (a few years ago, when I first started using 7zip as a secondary compression program), I recall poring over maximumcompression.com for a good long time and coming away with the distinct impression that WinRAR and 7zip were both pretty respectable, but in practical real-world use, there was no reason to stop using WinRAR. One of the reasons being, even at that point in recent memory, 7-zip still had bugs of a nature that could conceivably lead to you compressing your files and not being able to uncompress them! (Yes, putting your data at risk!) The reliability just wasn't there, for it to be my go-to permanent archiver.

Overall: sorry, but it's not a very impressive article, and so, by extension, not a very impressive award.
 
Testing compression performance without testing decompression performance is weird, and doesn't really reflect typical real-world use of this software. There are far more consumers of archived content than creators, after all. Granted, someone just looking to extract some files may be less likely to buy software for it than someone who compresses a lot of files, but it's still very relevant for both types of users.

I've been using 7-zip as my primary archiving utility for a few years, and its a good piece of free software, but it does have its issues. Its decompression speed may not be as fast as some other utilities, and there can be other performance issues in certain situations, like extracting files to a temp directory before moving them to their final location, which can cause a significant performance hit when using multiple drives and partitions. Calling it the "clear performance winner" seems a bit unwarranted when only compression performance is tested, and may be somewhat unfair to the paid utilities. I'm unlikely to switch to a paid compression utility when free alternatives like 7-zip work reasonably well, but I'd still like to see decompression performance in a roundup of file archivers. You might not end up with such a clear, overall winner, but the results would be a lot more useful to the majority of users who extract more archives than they create.
 

digigamer

Honorable
May 29, 2013
10
0
10,510
Missing Peazip (http://peazip.org). It's an FOSS app. Plug-in based like MagicRAR and can handle almost any formats you throw at it. And about compression, LZMA2 is undoubtedly best for general purpose usage but RAR takes a hit when compressing media files. If your file set is wholly media files and you enable media compression in RAR, the results are different.
 
Status
Not open for further replies.