I normally use WinRAR over 7-Zip simply because it's faster and only a little less efficient with compression. I did a few tests on different file types and sizes comparing the 7-Zip and WinRAR default settings on their normal compression and their best compression, and in a lot of cases WinRAR was 50% faster and in some it was actually 100% faster. But, I do like FOSS more. So here are my questions:

  1. Is there a way to make 7-Zip speed-up? I'd like it to at least be on par with WinRAR's speed
  2. Is there a way to make recovery segments in 7-Zip like you can in WinRAR? I didn't see any, but I guess it could be a command line thing.
  3. I tested WinRAR and 7-Zip using the latest stable version of each (4-dot-something with 7-Zip). Is the 9.x beta release noticeably faster at compression?

I'm talking about faster at a comparable setting in WinRAR, not just lowering to bare minimum compression.

If it matters, I use a quad core Intel i7 720 (1.6 GHz)/(2.8 GHz) with 4 GB DDR3 RAM, and the 64-bit version of 7-Zip, and dual-boot Debian x64 5.0.4 and Windows 7 Home.

  • 1
    Regarding #2 -- 7-zip does not currently have any sort of "recovery record" or "ecc" ability. You'll need 3rd party software like QuickPar/MultiPar or ICE ECC, but then it's not part of the archive.
    – afrazier
    May 25, 2010 at 17:19

7 Answers 7


If you get the 7-Zip 9.13 beta you can change the archive type to LZMA2 and thus be able to use as many threads as you like, though the memory usage goes up phenomenally.

Install the beta, right click the stuff you want to archive then under the 7-Zip contect menu click "Add to archive..." and you will get something similar to the window below. On the left hand side under Compression Method you should find "LZMA2" which will allow you to change the number of threads which will be an option a bit further down.

This has the potential of vastly increasing performance on >2 core processors as it can be better tuned to your system, and the normal compression method can only handle 2 threads maximum.

The "/1" you see to the right of the number of threads selection box in the image is the number of processors in your system and thus the recommended number of threads. My i7 is a quad core processor but has hyperthreading (which does actually help here btw) so it shows as "/8"

alt text

  • Anandtech.com has been using 7-Zip to help benchmark the performance improvements to be found in multi-core and multi-threaded CPU's, which otherwise is more theoretical in most of this generation's software.
    – kmarsh
    May 25, 2010 at 13:11
  • 5
    What is the command line arg to enable LZMA2 ?
    – djangofan
    Apr 4, 2012 at 18:28
  • @Monkubai: IN the i7 4c-8t in my office, I can't get the 7-zip run full 8-core in LZMA2 mode whatever setting being set. Only method allow it runs all 8-threads is using BZip2 algorithms (from drop-down menu) which has lower compression ratio.
    – Edward
    Nov 11, 2014 at 9:14
  • 2
    @Mokubai 9.20 official version. And there's nothing wrong with graphic UI, it still displays 8/8 cores parameter in setting panel but when processing it actually only use <20% cpu. I did a quick research in SU for the issue but haven't yet figured out the reason for that odd. Just know that if I use command line 7z with parameter such as -m0=lzma2 -mmt=8 then compression ultilizes ~100% CPU but once I switch to GUI, it returns to single-thread mode or something like that... which make use of CPU in a very inefficient way (<20%).
    – Edward
    Nov 12, 2014 at 9:05
  • 1
    Hey look, a windows XP screenshot! It's been a while.
    – Marc.2377
    Oct 28, 2019 at 9:41

As each thread seems to compress multiple files at the same time, the best thing you can do to increase performance of very large zip jobs is to set threads to 1, to be sure that your hard drive will seek one file at a time.

We improve performance on all our daily zip-backup procedures by adding -mmt=off to 7-zip command line. Our backup of the "visual SVN repository", which is made from multiple small files, was taking between 50 and 60 minutes.

With -mmt=off, we now always do in in less than five minutes! And, during these 50 minutes, all our servers were very slow because of the hard drives seeking. Now, everything remains very fast during those five minutes.

For everything you do on a machine, the hard drive activity will always be slower than your CPU capacity. You can increase disk performance by disabling parallel activities and making sure that the hard drive reads (and write) your files one by one serially.

Also it's better to read from disk1 and write your ZIP to disk2, as the physical head does not move from read to write.

Sample line to get maximum ZIP speed while keeping your machine performance:

start "" /wait /belownormal c:\Progra~1\7-Zip\7z.exe a -tzip -mx=1 -mmt=off t:\backup.zip d:\folderToBackup\*

D: and T: are 2 different physical disks

  • 7
    Amazing that this is the exact opposite of the suggested answer, but is actually correct. I just made an archive operation go from 12 hours down to 2 by changing to using a single thread.
    – N Jones
    Apr 19, 2015 at 23:15
  • 3
    True. This worked for me too. Probably it makes sense because he's using -mx=1 (which is almost no compression). If you are not compressing, most of the work is done by the HDD. If you set -mx=9 the processors really need to work to compress the file. I would need to try it, but depending on what the bottleneck is (HDD or CPU), it might be better or worse. Jun 5, 2015 at 21:49
  • 18
    This answer is very specific to an aging technology. It's probably not useful to try this with SSDs because the seek time is so much lower. The random IOPS is less likely to be the bottleneck. Your case was pretty special because you were performing very little compression. Basically you were doing a file copy. So yeah, sequential access on a spinning HD is clearly a winner. Typical 7zip usecases will likely be CPU bound, not IO bound. For that, using all CPU cores is essential. But for those in a similar situation, your advice is very valuable.
    – dss539
    Oct 6, 2015 at 22:16
  • 1
    Using -mmt=off is faster even with -m0=lzma2 -mx=5. (Without -mmt=off: real 1m27.811s, user 2m4.976s, sys 0m3.729s. With -mmt=off: real 1m18.896s, user 1m17.160s, sys 0m1.661s)
    – ostrokach
    Nov 29, 2015 at 22:51
  • Seems to be much slower for me to decrease threads to 1. With 1 thread for 20 GB of files it was processing at a speed of about 2 MB/sec. With 16 threads it was processing at about a speed of 16 MB/sec. Oct 13, 2016 at 17:06

In my company, we are working with an old version of 7-zip (4.52 beta), and we are running the following command:

"C:\Program Files\7-Zip\7z.exe" a -mx7 -mmt -sfx -xr!*.<exclude_extension> <destination>.exe <source_directory>\* 

This is working fine, but after just having upgraded to the newer version 16.04 (32-bit), the performance has dropped enormously, so I've decided to downgrade back to the old version.


Another little trick to improve performance when you use code like this example:

$7zip = "$env:ProgramFiles\7-Zip\7z.exe"
set-alias sz $7zip
$FileZip = "$DiscoZip\temp\$TempFile"
foreach ($DirData in $ListDir) { $out7z = (sz a $FileZip $DirData) }

is, if possible, have in the array $ListDir listed the directories by size, from the smallest to the largest. This happens because at each foreach cycle 7zip creates a temporary file that is as large (or larger) than the original one, then add new file inside them. I have tried with cases in which there are two or more directories large some MB and one large many GB and the saving of time is in the order of several minutes.

  • I believe this only applies when adding files to an existing archive. When adding multiple files at once, only one temporary file would be used. When creating a new archive, a temporary file would not be used at all.
    – Daniel B
    Oct 19, 2018 at 9:59

You don't need the beta version anymore. Just make a 7z or bz2 file for multithreading. Bz2 is faster. You can make a zip file with bz2 compression with the -m0 option (not -m like in the docs).


My guess is that speeding up 7-Zip is impossible without re-writing its compression/de-compression algorithms, there may be some kind of tweak that increases speed but it will probably only be like a 10 or 15% increase, not a massive 50-100% increase that you're looking for.

  • 6
    Not true at all. You can massively speed up 7-zip by simply changing it off the default settings. In fact the default settings are tuned for the smallest file size (and slowest compression algorithm - BZip2). Changing it to ZIP and LZMA compression set to "Fastest" makes it massively faster.
    – NickG
    Feb 24, 2015 at 11:33

All of the compression algorithms I've used recently (ZIP, RAR, 7z, tar/bzip2) are I/O bound, not CPU bound. Watching MenuMeters on my Mac laptop shows constant disk activity, but only 50% or less CPU activity.

Thus, the way to speed up compression/decompression is to speed up your disk. This isn't always possible.

My "solution" to this is to just do something else while I'm compressing something. :-)

  • 2
    If disk I/O was Matt's problem, it would mean that WinRAR is somehow able to read from disk faster than 7Zip on his system... That sounds unlikely to me.
    – foraidt
    May 27, 2010 at 9:12
  • 1
    It's possible that WinRAR uses smarter disk I/O; I know Info-ZIP's zip is hampered by its really small I/O buffers. But yeah, it could be a difference between the compression algorithms.
    – chrish
    May 27, 2010 at 17:22
  • 1
    7z is certainly not I/O-bound even in fast mode. Dec 15, 2014 at 10:42
  • Most of the methods you have described do not compress in parallel thus only 1 core of your CPU is used hence on a 2 core machine you get 50%. I'm afraid that are CPU bound on your mac, not IO bound and most macs have SSD that don't really suffer from disk seeks. 7z can compress in parallel if you choose the option to do so. (tar, zip, bzip, gzip, xs generally don't)
    – Martin
    Apr 7, 2016 at 8:52

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .