zlib vs gzip.compress Same Level: Localhost Lab

Intro — what this post promises

In-memory compress/decompress of a compressible fixture via zlib.compress / zlib.decompress vs gzip.compress / gzip.decompress at the same level (6). This lab reports MB/s and output size on Linux localhost.

It is not the multi-codec zstd/gzip/lz4 bake-off (lab 33) and not nginx gzip toggles (lab 20). Here the question is only: Python stdlib zlib vs gzip wrappers.

Related links:

• 01shoppercove.comzstd vs gzip lz4 compression localhost lab
• 02shoppercove.comnginx gzip on vs off localhost lab
• 03shoppercove.comqueue vs deque handoff localhost lab
• 04shoppercove.comstringio vs list join localhost lab
• 05shoppercove.comgroupby vs manual localhost lab
• 06shoppercove.commethodcaller vs getattr localhost lab
• 07shoppercove.comhmac compare digest localhost lab
• 08shoppercove.comargparse vs sys argv localhost lab

Lab honesty (1 Oct 2026 IST): Python 3.13.5. Affiliates: 0. No Docker. Level 6. Fixture = repeating JSON-ish lines (highly compressible).

Verdict up front (1 MiB): gzip.compress ~335.4 MB/s (out 3661 B); zlib.compress ~320.0 MB/s (out 3649 B); decompress gzip ~994.4 / zlib ~905.3 MB/s. Gzip adds a fixed ~12 B header/trailer overhead on this box.

Arms

Lab topology

sizes: 256 KiB · 1 MiB · 4 MiB · level=6 · 7 rounds · p50
metric: MB/s = in_bytes / p50_s / 1024² (decompress vs original size)

Script: lab-evidence/102-zlib-vs-gzip-compress/results/run_lab.py.

Lead table — 1 MiB (p50)

Gzip overhead vs zlib blob: 12 bytes (header + CRC trailer). Throughput is in the same ballpark — framing cost is tiny next to DEFLATE work.

Scale sketch (compress MB/s)

What gzip adds

gzip.compress is zlib DEFLATE plus a gzip header and CRC32/ISIZE trailer. Use gzip when peers expect .gz / HTTP Content-Encoding: gzip. Use raw zlib (or raw DEFLATE) when you own both ends and want a smaller envelope (e.g. some wire protocols).

Streaming note

This lab uses one-shot compress/decompress on full buffers. Chunked compressobj / GzipFile changes memory profile and can change throughput — re-measure if your pipeline is streaming.

Reading it

• Same level ⇒ nearly identical compress rates; pick the container, not the mythical faster twin.
• Decompress is several× compress here (compressible payload).
• Tiny fixed overhead matters more on small blobs than on multi‑MiB ones.
• For codec shopping (zstd/lz4), go to lab 33 — not this post.

Level fairness

Always pin the same compresslevel (here 6, zlib/gzip default band). Comparing zlib-1 to gzip-9 is a common blog mistake and says nothing useful about framing overhead.

Wire format reminder

HTTP Content-Encoding: gzip, .gz files on disk, and many CLIs speak gzip. Some databases and custom RPCs prefer zlib or raw DEFLATE. Matching the peer’s expected magic bytes matters more than the ~tens of MB/s delta on this box.

Pitfalls

• Comparing zlib level 6 to gzip level 9 (unfair).
• Forgetting gzip framing when a client expects zlib-only (or vice versa).
• Using this highly repetitive fixture as a ratio benchmark for “typical” traffic.
• Conflating Python API speed with nginx gzip filter cost (lab 20).

Reproduce

python3 lab-evidence/102-zlib-vs-gzip-compress/results/run_lab.py

Evidence: summary.json, summary.txt.

Limits

One Linux box. Synthetic repeating JSON lines (very compressible). Level fixed at 6. Not streaming zlib.compressobj / GzipFile chunked APIs.

Takeaway

At 1 MiB level 6, gzip.compress ~335.4 MB/s and zlib.compress ~320.0 MB/s — choose gzip for interoperability, zlib for a leaner envelope (+12 B for gzip here).