7-Zip Memory Usage: Compression vs Decompression

In 7-Zip, compressing an archive requires substantially more random-access memory (RAM) than decompressing it. While decompression only requires enough memory to hold the sliding dictionary window and minimal operational buffers, compression must store the dictionary, track search trees, and analyze data patterns across multiple CPU threads. This guide breaks down the technical reasons behind this memory disparity, the role of dictionary size, and how settings impact system resource usage.

The Asymmetric Nature of LZMA and LZMA2

The default and most popular compression algorithms in 7-Zip are LZMA and LZMA2. These algorithms are inherently asymmetric in terms of computational workload and memory consumption:

  • Compression requires searching: The compression engine must analyze uncompressed data, locate repeated byte sequences, and determine the most efficient way to represent them. To do this, 7-Zip utilizes match finders (such as Binary Trees or Hash Chains) that require large data structures kept entirely in RAM.
  • Decompression requires following instructions: The decompressor does not need to analyze or search data. It simply reads tokens from the compressed stream, looks back into the historical data window (the dictionary), and copies the referenced bytes directly to the output.

The Role of Dictionary Size

The dictionary size is the single most significant factor determining memory consumption in 7-Zip:

  • Decompression Memory Requirement: The memory needed to decompress an archive is roughly equal to the dictionary size used during compression, plus a small overhead (typically a few megabytes for buffers). For instance, an archive compressed with a 64 MB dictionary requires approximately 66 MB to 70 MB of RAM to unpack.
  • Compression Memory Requirement: Compression requires significantly more than the baseline dictionary size. Depending on the chosen compression level (Fast, Normal, Maximum, or Ultra) and the match-finding method (e.g., BT4), the compression engine typically requires 10 to 12 times the dictionary size per thread. If you set a 64 MB dictionary for a single thread, compression can easily demand around 600 MB to 700 MB of RAM.

Multi-Threading Multipliers

Multi-threading amplifies memory consumption during compression far more than during decompression:

  • During Compression: When using LZMA2, 7-Zip divides the data stream into chunks and processes them across multiple CPU threads. Each active thread requires its own dictionary allocation and match-finding tables. If a system runs an 8-thread compression task with a 64 MB dictionary, total memory usage can quickly exceed 4 GB to 5 GB.
  • During Decompression: LZMA2 allows multi-threaded decompression, but because each thread only needs to retain the decoded window rather than heavy search structures, the memory footprint per thread remains small. Total decompression memory rarely poses a challenge even on systems with limited hardware.

Practical Implications

When creating archives intended for distribution, keep recipient hardware constraints in mind:

  1. Verify the 7-Zip GUI metrics: The 7-Zip compression dialog displays exact figures for "Memory usage for Compressing" and "Memory usage for Decompressing" dynamically as you adjust settings.
  2. Avoid unnecessarily large dictionaries: While increasing the dictionary size to 1 GB or higher can yield marginal compression improvements on large files, it forces anyone unpacking the archive to have that full amount of free RAM available.
  3. Prevent system thrashing: If compression memory exceeds available physical RAM, the operating system will rely on swap/page files on disk, drastically degrading performance.