Archiving 53 files took 0.04 seconds with Python zipfile

Archiving a small folder of 53 files totaling 318,661 bytes finished in 0.04 seconds only with Python's zipfile.

tar.exe took 2.59 seconds and PowerShell Compress-Archive took 2.03 seconds, so by the numbers zipfile was more than 60 times faster. At first I wondered whether this was a gzip-versus-deflate difference or whether the Windows-bundled bsdtar was slow on ARM64 Windows. Looking back, I started with the wrong question.

This is not a comparison of compression-algorithm speed. I should say that up front. The largest factor was how each tool was invoked.

zipfile runs as a library inside an already-running Python process. tar.exe starts an external command. Compress-Archive starts powershell.exe and runs a cmdlet inside it. In other words, the three methods did not measure the same thing. Putting the numbers side by side without equalizing that boundary is dangerous.

The core of this result is probably process-start time, not compression itself. The 318,661-byte input is small; even with 53 files, it is not enough work for compression itself to take two seconds, so fixed costs become prominent. Small archives are exactly where this trap appears. The measured values are dramatic, but the interpretation is ordinary.

Archiving the same folder three ways

The target was the same corpus folder containing 53 files, with an input size of 318,661 bytes. I compared two output formats, tar.gz and zip: the tar.exe that ships with Windows, PowerShell Compress-Archive, and Python's standard-library zipfile.

I invoked tar.exe like this:

tar.exe -czf c.tar.gz -C corpus .

I measured Compress-Archive by starting powershell.exe from outside:

powershell -NoProfile -Command Compress-Archive -Path "corpus\*" -DestinationPath "c.zip" -Force

The Python version used zipfile and added files one by one inside the same Python process. That is the largest difference in this comparison: it did not start an external process, so almost no startup wait was included. The invocation difference appeared before the compressor difference.

At first I thought all three could be listed as “time to create an archive.” After seeing the numbers, I reconsidered it as practical elapsed time including invocation, rather than a pure archive-processing comparison.

Output size and wait time

This was a single measurement, so I did not calculate a median. That is another weak point and a reason to rerun it. The values in this environment were:

By size, tar.gz was smallest at 87,976 bytes. The zip files were 140,406 bytes from Compress-Archive and 140,312 bytes from Python zipfile, almost identical. For this small corpus, gzip produced a considerably smaller result than zip's deflate.

Time went the other way: tar.exe took 2.59 seconds, Compress-Archive 2.03 seconds, and zipfile 0.04 seconds. The gap between tar.exe and zipfile was more than 60x, and zipfile was also far ahead of Compress-Archive.

However, it would be wrong to read the table as “zipfile compression is 60 times faster.” On my machine, only zipfile had a shorter measurement boundary. Python was already running, so I timed only the library call. tar.exe and Compress-Archive included starting the command, parsing arguments, and initializing PowerShell.

Where I almost went wrong

The failure was that, on first seeing the numbers, I almost concluded that Python had won the compression contest.

The 0.04-second value is conspicuous. Next to 2.59 seconds it looks like an implementation difference. But the foundations differ: tar.exe starts one process; Compress-Archive starts one powershell.exe and runs a cmdlet inside it; zipfile includes none of that. The compressors did not start from the same line.

Until I noticed this, I was questioning the bsdtar implementation and gzip settings. I should have questioned the measurement boundary first. The smaller the input, the more fixed startup cost dominates. With 318,661 bytes, startup cost beats the compression calculation.

Compress-Archive especially needs care. Calling it from a PowerShell script that is already running should produce a different value from 2.03 seconds. This test measured from starting powershell.exe, so it is not the pure speed of the cmdlet.

It still matters in practical work

The benchmark is unfair, but it can still inform a script choice. In practice, the elapsed time including invocation is often exactly what matters rather than compression in isolation.

For example, if a Python automation script needs to make small archives, keeping the work inside zipfile will wait less than invoking external tar.exe or powershell.exe. For one archive the difference is only about two seconds, but for dozens of small archives the fixed cost accumulates.

For a one-off manual command, it may not matter. If the desired output is the 87,976-byte tar.gz, waiting 2.59 seconds is reasonable. When artifact size is the priority, there is still a reason to use tar.exe.

Compress-Archive is a natural way to make a zip, but starting powershell.exe externally makes it heavy. If PowerShell is already running, the situation is different. Whether the zip is made by an external command or by a library or cmdlet inside the existing process changes the experience.

What I would measure next

Next I want to split the conditions: one measurement for practical elapsed time including process startup, and one for pure compression in an already-running environment.

As a small experiment on July 7, 2026, the useful conclusion is that for a small folder such as 53 files and 318,661 bytes, invocation overhead is more visible than the compression algorithm. I would like to repeat it with several hundred MB of real data; at that size, the actual compression differences among tar.exe, Compress-Archive, and zipfile should be easier to see. The 0.04-second result is interesting, but I keep it as a warning that the three tests measured different things, not as proof of fast compression.