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.
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.
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.
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
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).
Lzma2 is faster when using 4 or more cores and it gives better compression. This document explains it all.
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.
The link can be found on wayback machine :
https://web.archive.org/web/20221015140740/http://www.maximumcompression.com/data/summary_mf2.php
(was annoying to reformat the table - can wonder why it can't convert a html table into its own format)
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 |
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
with
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.