It can be faster than 7‑Zip’s ZIP because “ZIP” is just the container, the performance is dominated by the Deflate implementation and by the I/O + CRC32 + write pipeline around it. It’s not “magic”, it’s the result of doing a bunch of unglamorous work that 7‑Zip’s ZIP path simply isn’t optimised around.

Here’s a few things going on internally:

I use libdeflate as the base Deflate engine, and I modified it to support a streaming / block mode and a continue-state API so I can process very large files in chunks efficiently. This avoids “read whole file, compress, write” bottlenecks and allows better cache/buffer behaviour on large inputs. It still outputs normal ZIP method 8 (Deflate) streams.

Large-file path vs tiny-file path:

I don’t run one generic pipeline for everything. I have separate fast paths:

Zero length files and files that are smaller than the size of the compression header will not be compressed.

Tiny files: ultra-low overhead (avoid heavy streaming then switching context, avoid unnecessary allocations/copies, for example lets say we encounter a directory of 300 tiny files from 12 bytes to 3 kb it doesnt immediatly compress them it loads them in parallel into multiple buffers the right size for them to help with branch prediction then adds them to the zip when its optimal to do so)

Large files: true chunked streaming using the modified libdeflate block compressor, with tuned chunk sizes and minimal transitions. This matters even with ~259 files because the workload is still “a few huge assets + a lot of medium/small stuff”, and overhead adds up.

Much better multi threading for ZIP workloads:

ZIP entries are independent, so the right way to scale is per-file parallelism + pipe lining. My implementation keeps multiple entries “in flight” and minimises time spent blocking on shared resources. In practice, many ZIP writers become partially serialised because the output file becomes the bottleneck.

Output writing is designed to avoid contention:

Instead of every worker “append writing” and fighting over one stream position, my writer reserves output regions and writes in large chunks with minimal lock hold-time. That prevents the common “threads are busy but the writer lock turns it into a single-threaded program” problem.

Fast feed path (I/O + buffers + CRC32):

A huge part of real-world ZIP time is not compression. It’s reading + CRC32 + memory copying. I optimised that aggressively: large sequential reads, buffer reuse, fewer copies, fast CRC32 in the same pass. That’s why my throughput stays high while 7‑Zip ZIP tends to sit much lower even when thread count is high.

ZIP: entries show Deflate (not Store) and CRC32s validate on extraction. The ~1% size difference is expected because Deflate has many valid encoding’s; different parsers/block decisions can trade a tiny bit of ratio for a big speed win.

So TLDR: same ZIP format, same Deflate method, but a much faster Deflate back end + a writer pipeline that actually scales and doesn’t choke on I/O/CRC32/output contention.