enter image description here

So there are different compression methods in 7zip. Which method is best suited for what task?

For example: One difference between LZMA and LZMA2 is I can choose all my cpu cores, whereas in LZMA 2 cores is the max.


5 Answers 5


Use LZMA 2 unless you are looking to extract the archive on a system that cannot deal with LZMA 2 archives.

Generally speaking most modern compression algorithms give roughly the same compression, and with regard to the number of cores that you can use at once, it is up to you to decide how many you want to use. Generally speaking (unless you are creating large archives) there is no reason to need more than one though. In addition, with multiple cores doing the compression, the bottleneck may become the hard drive.

  • 3
    side note: the better compression results ("ultra") are mostly bought by cpu and (important) ram. lzma2-ultra-dictsize(64mb)-4threads will eat 2+gb of ram, bzip2-ultra-dictsize(900kb) will eat 69mb of ram.
    – akira
    Jun 3, 2012 at 8:17

7-Zip (at least as of 2019-09-27) has a built-in Help document with a very, very nice explanation of the various settings you can choose and what, in general, each is good for.

There's no benchmark results or anything, but it was enough information to instill some confidence in me that I was picking "good enough" and not "accidentally awful" settings.

The Help document is available through the 7-Zip File Manager as well as the Add to Archive dialog box.

The "Contents" path to the page I found useful (which opens up directly from the Add to Archive dialog box) is:

File Manager / Plugins / 7-Zip / Add to Archive Dialog Box

enter image description here

Here is a rough copy/paste of the compression method section:

Method Description

  • LZMA
    • It's base compression method for 7z format. Even old versions of 7-Zip can decompress archives created with LZMA method. It provides high compression ratio and very fast decompression.
  • LZMA2
    • Default compression method of 7z format. LZMA2 is LZMA-based compression method. It provides better multithreading support than LZMA. But compression ratio can be worse in some cases. For best compression ratio with LZMA2 use 1 or 2 CPU threads. If you use LZMA2 with more than 2 threads, 7-zip splits data to chunks and compresses these chunks independently (2 threads per each chunk).
  • PPMd
    • Dmitry Shkarin's PPMdH algorithm with small changes. Usually it provides high compression ratio and high speed for text files.
  • BZip2
    • Standard compression method based on BWT algorithm. Usually it provides high speed and pretty good compression ratio for text files.
  • Deflate
    • Standard compression method of ZIP and GZip formats. Compression ratio is not too high. But it provides pretty fast compressing and decompressing. Deflate method supports only 32 KB dictionary.
  • Deflate64
    • Modified version of Deflate algorithm with bigger dictionary (64KB).
  • 7
    Great find. I never knew why my files compressed with LZMA2 were about 2% bigger than compressed with LZMA. Now reducing the number of threads from 32 to 2 they get even about 1% smaller. :)
    – Robert
    Feb 6, 2020 at 22:47
  • PPMd compression is 3x faster than xz, but PPMd decompression is 20x slower than xz, based on my data (text files)
    – milahu
    Nov 26, 2023 at 22:13

Lzma2 is faster when using 4 or more cores and it gives better compression. This document explains it all.

  • 10
    I'm not saying the document is unusable, but it has a range of problems. Prominently, the author does not even specify what kind of data is being compressed (text? pictures? encrypted data?), does not use relative sizes where applicable and does not seem to understand solid archives at all.
    – mafu
    May 16, 2016 at 13:24
  • 2
    You forgot to mention that using Lzma2 gives worse compression when using 4 or more threads. This is because the work is split up. From personal experience I think the best compression rate can be achieved with Lzma2 running on 3 or less threads.
    – Robert
    Feb 7, 2020 at 0:18
  • The link is pay-walled/registration-walled/requires you to upload files(???) to access the document. Mar 28, 2023 at 7:34

Take a look here: http://www.maximumcompression.com/data/summary_mf2.php#data and sort by efficiency. I personally wish FreeArc was built into 7-zip, and do use it sometimes.

  • 1
    Wouldn't it make more sense to sort by compression ratio? Dec 5, 2018 at 0:39
  • 2
    FreeArc is supported by PeaZip (an archive filemanager, just like 7zip's filemanager). Even though FreeArc is old, it still outperform by a magnitude any LZMA(2), e.g. 7zip, and other compressors in ratio and speed. And it even have recovery blocks. It's nothing less than catastrophic the project is dead and not developed anymore. The community should in unity finance someone to bring it up to date.
    – MrCalvin
    Jul 15, 2020 at 21:02
  • Agreed anyone want to take a lead on it? Jul 20, 2020 at 3:41
  • 1
    The link is dead. Please try to provide a snippet next time. Mar 28, 2023 at 7:33

The link can be found on wayback machine :


(was annoying to reformat the table - can wonder why it can't convert a html table into its own format)

Summary of the multiple file compression benchmark tests

File type : Multiple file types (46 in total)

# of files to compress in this test : 510

Total File Size (bytes) : 316.355.757

Average File Size (bytes) : 620,305

Largest File (bytes) : 18,403,071

Smallest File (bytes) : 3,554

This test is designed to model 'real-world' performance of lossless data compressors. The test set contains a mix of different file types which are chosen with 'What do people use archivers for the most' in mind. The testset should contain data, weighted (in both type and proportion of files in the set) by how often these files are used for compression by normal users using compression software. So for example there will be more txt files then .ocx files in the set (yes, this is arbitrary). The set contains 100's of files and has a total size of over 300 Mb. The idea of a large collection is filtering out the 'noise'. A compressor might perform bad on 1 or 2 filetypes, but on a very large collection it will not hurt as much.

Some programs like CCM and BZIP2 can only compress one file at a time. For these programs a single TAR-file is created containing all files. The files in this TAR-file are ordered alphabetically on suffix, then name. Results of these compressors are marked with an 'Y' in the tarred column.

The testset consists of the following file types :

Filetype(s) Description % of total # of files
TOC, MBX Eudora mailboxes 12.31 16
EXE, DLL, OCX, DRV Executables 10.99 35
TXT, RTF, DIC, LNG Text files in several languages 10.21 41
BMP, TIFF Bitmaps/TIF images 7.88 15
LOG Log files 6.34 6
HTM, PHP HTML files 6.13 19
DOC MS Word files 6.08 30
C, CPP, PAS, DCU Source Code 6.00 235
MDB, CSV Databases 4.26 7
HLP Windows Help files 4.23 7
CBF, CBG Precompressed chess-databases 3.55 2
WAV Wave soundfiles 3.45 9
XLS XLS Spreadsheets 2.41 16
PDF Adobe Acrobat document 1.59 6
TTF True Type Fonts 1.15 15
DEF Virus definition files 1.10 3
JPG, GIF Image files 0.53 9
CHM Precompressed help files 0.49 2
INI, INF INI files 0.42 10
Others DAT,JAR,M3D,SYS,PPT,MAP,WP,RLL,RIB.. 10.88 27

Considering the fact it's supposed to be a 'real-world' test I will not look at the best possible (command-line or gui) switch combination to use for optimal compression, but only test a limited set as 'normal users' would do. For 7-zip this means for example I will use the GUI and select the Ultra compression method (which can be easily beaten with some good command line switches), WinRar will be tested with max dictionary size and solid archiving etc. Programs are allowed to use a maximum of 800 MB memory and must finish the compression stage within 12h. Compressed size must be 50% or less compared to the original size to be listed on MFC.

For my single file tests I got lots of requests to add the compression time to the tables. I did not do this for the reasons stated in the single file summary file, but I'm planning to measure compression times for this multiple file test!. I also decided to make this testset 'non public', so it's harder for developers to tune their program towards this specific test. I think this is the most fair way to get 'real life' performance tests.

Scoring system: The program yielding the lowest compressed size is considered the best program. The most efficient (read:use full) program is calculated by multiplying the compression + decompression time (in seconds) it took to produce the archive with the power of the archive size divided by the lowest measured archive size. The lower score the better. The basic idea is a compressor X has the same efficiency as compressor Y if X can compress twice as fast as Y and resulting archive size of X is 10% larger than size of Y. (Special thanks to Uwe Herklotz to get this formula right)

score_X = POWER(2; ((size_X / size_TOP) - 1) / 0,1) * time_X


  score_X     efficiency score for a certain compressor X

  time_X      time elapsed by compressor X (comp + decomp time)

  size_X      archive size achieved with compressor X

  size_TOP    archive size by top archiver (smallest benchmark result)

Formula to calculate compressor efficiency based on compressed size and compression time

"0,1" represents 10% and power of 2 ensures that for each 10% worse results (compared with top) the time is doubled, so any archiver (except top compressor) will get a penalty on time. The score of top compressor is always equal to its time value.

You must log in to answer this question.

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