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.
Facebook
Twitter
Instagram