GitHub - marksmayo/blazezip: A very fast, parallel, standards-compliant ZIP archiver for Windows, with a benchmark suite

A very fast, parallel, standards-compliant ZIP archiver for Windows, plus a benchmark suite that pits it against 7-Zip, NanaZip, PeaZip, Bandizip, WinRAR, WinZip, Info-ZIP, pzip, zstd, pigz, LZ4 and LZFSE and awards medals. On the test machine it wins more gold medals than any other tool in both suites; see Performance.

blazezip is Windows-only: it uses Windows file APIs directly for its speed.

Installing

Download blazezip-<version>-x86_64-pc-windows-msvc.zip from Releases, unzip it and put blazezip.exe on your PATH. Each release has a .sha256 checksum next to it.

To build from source you need Rust 1.85 or later (MSVC toolchain). LLVM's clang-cl is optional but recommended: with it, libdeflate gets its fastest (BMI2) decoder.

cargo build --release        # target/release/blazezip.exe
cargo test --release

Using blazezip

blazezip c out.zip folder [more inputs...]   # create (Deflate, level 6)
blazezip c out.zip folder -1                 # fastest   (-12 = smallest)
blazezip c out.zip folder --zstd             # Zstandard inside ZIP (method 93)
blazezip a out.zip more-files                # add (replacing same-named entries)
blazezip d out.zip folder/old.txt            # delete entries (or whole directories)
blazezip x out.zip -o dest                   # extract
blazezip x out.zip folder/a.txt -o dest      # extract only the named entries
blazezip t out.zip                           # verify CRCs without writing
blazezip l out.zip                           # list

Options: -t N threads (default: 8 when creating Deflate archives, up to 12 for small inputs at -7 and above; otherwise all logical CPUs), --chunk MiB, --no-store, -q, -V/--version. The thread count never changes the archive: the same inputs and options give the same bytes.

Exit codes: 0 on success, 1 on any error. 1 is also returned when the job finished but not cleanly: input files that could not be read were left out of the archive (and named on stderr), or a damaged archive was only partly recovered.

Why it's fast

• Everything is parallel. Files compress concurrently (runs of small files are batched into one job); a single large file is split into 1 MiB chunks that compress on all cores. The input tree is walked in parallel. A bounded in-flight window (in jobs and bytes) keeps memory proportional to the thread count rather than the input size, and output buffers are recycled.
• libdeflate does all Deflate work. It is vendored in third_party/libdeflate with one small addition, libdeflate_deflate_compress_sync(), which ends a chunk with a sync flush instead of a final block. The chunks concatenate into one ordinary Deflate stream that every unzip tool reads. With LLVM installed, libdeflate is built with clang-cl, which (unlike MSVC) can build its BMI2 decompressor and fastest CRC-32; blazezip uses that CRC-32 too.
• Parallel decompression of single large files. blazezip records each chunk's compressed size in a private extra field (0x7a42) that other tools ignore. On extraction, every chunk is decoded independently, straight into a memory-mapped output file.
• Incompressible data is detected and stored. Samples are test-compressed first, so photos, video and existing archives skip pointless work.
• Only the threads that help. Storing incompressible data is I/O-bound, so creation uses two threads plus one per MiB that actually needs compressing. Extraction stops adding threads once the largest file, not the thread count, sets the finishing time.
• Windows-aware I/O. Directories are created up front (a level at a time, in parallel), files are created from many threads (NTFS file creation parallelises well; for many small files, twice as many threads as cores), handles are closed on separate threads because closing a freshly written file is where antivirus scanning blocks, and large stored entries are streamed with ReadFile and WriteFile instead of page-faulting a mapping. The process opts out of Windows power throttling so it isn't parked on efficiency cores.

Archives are plain ZIP (Zip64 when needed), verified with 7z t and Info-ZIP unzip -t. They record Windows attributes (read-only, hidden, system) and NTFS timestamps (100 ns), which blazezip and 7-Zip restore on extraction. A file that cannot be read (locked by another process, say) is skipped with a warning and a non-zero exit code; everything else is archived. An interrupted or failed run never leaves a partial archive behind. Adding and deleting copy the other entries' compressed data unchanged, and if an archive's central directory is missing (a truncated download, say), extraction recovers what the local headers still describe and exits with an error.

Performance

Measured on 12th Gen Intel(R) Core(TM) i7-12700H (14 cores, 20 threads), 31.7 GB RAM, NVMe KXG70ZNV512G NVMe KIOXIA 512GB, Windows 11 (10.0.26300), with Windows Defender real-time protection on. Every test runs 10 times under a Windows Job Object; the median of the fastest five runs is reported. Competitors keep their best result across recent runs, blazezip shows its latest. Tool versions are listed below. Generated by python bench/readme_perf.py on 2026-10-15.

Main suite: medal table

Every benchmark awards gold, silver and bronze for each metric: wall time, CPU time, peak memory and (when creating) archive size.

Where blazezip wins

Gold medals won by blazezip, by metric: Speed (wall) 34/42, CPU time 14/42, Peak memory 4/42, Size 3/27.

Each cell is blazezip's result and its place; where it is not in the top three, the best tool's result is shown for comparison. Sizes are the archive as a share of the input.

Charts

blazezip is highlighted in orange.

Extended suite

The extended suite covers behaviour as well as speed: scaling, start-up time, very large and very many files, Unicode and legacy names, metadata, corrupt and hostile archives, locked files, interruption, memory caps and more. Each (test, metric) pair awards medals; ties share a place.

blazezip places first in 55 of the 125 ranked metrics it takes part in.

Corpora and tool versions

Benchmarks

python bench/bench.py                 # everything: all corpora, 10 runs per test
python bench/bench.py --quick         # fewer corpora, still 10 runs per test
python bench/bench.py --corpora silesia,linux --tools blazezip,7zip
python bench/bench.py --reps 10 --keep-best 5         # busy machine: drop the 5 slowest runs
python bench/bench.py --resume results/<run>          # continue an interrupted run
python bench/bench.py --report                        # rebuild results/latest-report.html

Each run writes results/<timestamp>/results.json and report.html, and copies the latest report to results/latest-report.html.

What is measured. Every command runs under benchrun (bench/benchrun), which launches it inside a Windows Job Object and reports wall time, total CPU time and peak committed memory for the whole process tree. Every test runs 10 times and the median is reported (with --keep-best K, the median of the K fastest runs). Benchmark builds of blazezip target the local CPU (x86-64-v3 when AVX2 is available) and compile the C libraries with clang-cl when it is installed; ordinary release builds stay portable.

Benchmarks.

Medals go to the top three per benchmark for each metric: speed, CPU time, memory and, for compression, output size. Only verified results count: created ZIPs must pass 7z t, extractions are hash-checked file by file, and native round-trips must be byte-identical.

Extended suite. python bench/extended.py measures 91 further metrics on every tool, each with medals:

• speed with one CPU, at 1/2/4/8/all CPUs, under full CPU contention, two jobs at once, under a 256 MiB memory cap, in a Defender-scanned folder, and time to first byte;
• how much a tool slows other programs (p99 lateness of a 10 ms timer while it works);
• workload shapes: 100k tiny files, a 4.6 GiB file, paths over 260 characters, Unicode names, sparse and zero files, a mixed home-folder tree, JSON logs, a SQLite database, a git checkout, Word and PDF documents, 70k and 1M entries;
• the whole speed/size curve: every compression level, the area under it, and the smallest archive within 1, 3 and 10 seconds;
• operations: add, delete, update, extract one file, list and test, also on 100k- and 1M-entry archives;
• resources: working set, bytes read and written, temp space, threads, handles, page faults, start-up cost and tool size;
• archive quality: Pareto efficiency, size per CPU-second, per-entry overhead, reproducibility, and decode cost for a neutral reader;
• Windows file-system cases: device names (aux.h), junction loops, hard links, Mark of the Web, case-only name clashes, read-only and unwritable destinations, live-growing files, folder times and dates outside 1980-2107;
• archives from elsewhere: legacy code pages, macOS clutter, Unix symlinks, Deflate64, BZip2, LZMA, PPMd, XZ and Zstandard entries, NFC/NFD names, comments, and encryption;
• safety and correctness: five independent readers, metadata, Zip64, UTF-8 flags, locked inputs, corruption detection, CRC and size mismatches, overlapping zip bombs, truncated and damaged-end recovery, zip-slip, exit codes and Ctrl-C clean-up.

A few metrics (cold cache and first run, HDD, USB and network targets, energy, disk full, power-saver) need hardware or administrator rights; the report lists them with the reason. Metrics where every tool ties award no medals. Each run goes to results/ext-<timestamp>/extended.html; results/ext-latest-report.html combines every competitor's best result with blazezip's latest. python -m pytest bench/tests tests the suite's own helpers.

Corpora. All are standard or deterministic: Silesia (the standard compression benchmark), the Canterbury large corpus, enwik8, a Linux 6.6 source subset, real Windows binaries, and synthetic incompressible media.

Getting the competitors

Most install with winget: 7zip.7zip, M2Team.NanaZip, Giorgiotani.Peazip, Bandisoft.Bandizip, RARLab.WinRAR, Corel.WinZip with Corel.WinZip.CommandLineSupportAddOn, and Meta.Zstandard. The suite also looks in tools/ for the following:

• tools/lz4/: the official Windows release
• tools/pigz/: the Cygwin pigz build with cygwin1.dll and cygz.dll
• tools/lzfse/: built from https://github.com/lzfse/lzfse with MSVC
• tools/winrar/: a portable copy unpacked from the WinRAR installer
• tools/pzip/: go install github.com/ybirader/pzip/cmd/{pzip,punzip}@latest

WinZip's command-line add-on only works after WinZip has been opened once to accept its trial or licence.

Licence

blazezip is released under the MIT licence. It includes libdeflate (MIT) and Zstandard (BSD-3-Clause); see THIRD_PARTY_NOTICES.md.