53ファイルを固めたら Python zipfile だけ0.04秒だった

53ファイル、318661バイトの小さなフォルダを固めたら、Python の zipfile だけ0.04秒で終わった。

tar.exe は2.59秒、PowerShell の Compress-Archive は2.03秒で、数字だけ見ると zipfile が60倍以上速く、最初に見たときは gzip と deflate の差か、Windows 同梱の bsdtar が ARM64 Windows で遅いのかと疑った（今見ると、そこから疑う順番が少し違っていた）。

とはいえ、これは圧縮アルゴリズムの速度比較とは違う。この点は早めに白状しておく（あとから見ると、いちばん大きいのは圧縮より呼び出し方だった）。

zipfile は、すでに起動している Python の中でライブラリとして動く。tar.exe は外部コマンドを起動する。Compress-Archive はさらに powershell.exe を起動し、その中で Compress-Archive を実行した。つまり、3つの方法で「測っているもの」がそろっていない（ここをそろえないまま数字だけ並べると、かなり危ない）。

この結果の芯は、圧縮そのものではなく、ほぼプロセス起動時間だったと思う。318661バイトの入力は小さく、53ファイルあっても圧縮処理そのものが2秒もかかる量ではないので、固定費がかなり前に出る（小物を固める用途ほどこの罠を踏む）。実際に測った値は派手だが、解釈はかなり地味になる。

同じフォルダを三通りで固める

対象は同じ corpus フォルダに入れた53ファイル。入力サイズは318661バイトだった。出力は tar.gz と zip の2種類で、Windows に最初から入っている tar.exe、PowerShell の Compress-Archive、Python 標準ライブラリの zipfile を比べた。

tar.exe はこういう呼び方にしている。

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

Compress-Archive は powershell.exe を外から起動して測った。

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

Python 版は zipfile を使い、同じ Python プロセス内でファイルを順に足していて、ここが今回の比較で一番大きな差になる（圧縮器よりも呼び出し方の差が先に出た）。外部プロセスを起動していないので、起動待ちがほとんど入らない。

最初は3つとも「アーカイブを作る時間」として並べられると思っていた。実際に数字を見てから、これはアーカイブ処理の比較というより、呼び出し方込みの実務時間だと考え直している。

出力サイズと待ち時間

1回だけの測定なので中央値は出しておらず、この点も弱いところだ（あとで見返すと、ここは測り直してみる余地が大きい）。今回の環境では次の値になった。

方法	入力ファイル数	入力バイト数	elapsed_s	出力バイト数
tar.exe -czf	53	318661	2.59秒	87976
Compress-Archive	53	318661	2.03秒	140406
Python zipfile	53	318661	0.04秒	140312

サイズだけ見ると、tar.gz が87976バイトで一番小さい。zip は Compress-Archive が140406バイト、Python zipfile が140312バイトで、ほぼ同じだった。gzip と zip の deflate では、今回の小さな corpus では gzip 側がかなり小さく出ている。

時間は逆だ。tar.exe は2.59秒、Compress-Archive は2.03秒、zipfile は0.04秒。tar.exe と zipfile の差は60倍以上になる。Compress-Archive と比べても、zipfile はかなり離れている。

ただ、この表をそのまま「zipfile の圧縮が60倍速い」と読むのは間違いだ。私の環境では、zipfile だけ測定範囲が短い。Python はすでに動いている前提で、ライブラリ呼び出し部分だけを測っている。tar.exe と Compress-Archive は、コマンドの起動、引数の解釈、PowerShell 側の初期化まで含めている。

間違えそうになったところ

今回の失敗は、最初に数字を見た瞬間に「Python が圧縮で圧勝した」と思いかけたことだった。

0.04秒という値は目立つ。2.59秒と並べると、どうしても実装差に見える。けれど、よく見ると比較の土台が違う。tar.exe はプロセスを1本起動している。Compress-Archive は powershell.exe を1本起動して、その中でコマンドレットを動かしている。zipfile にはその部分がない（圧縮器の勝負というより、スタートラインの位置が違う）。

この勘違いに気づくまで、tar.exe の bsdtar 実装や gzip の設定を疑っていた。そこを掘る前に、まず測定範囲を疑うべきだった。小さい入力ほど、固定費が前に出る。318661バイトなら、圧縮の計算よりも起動の固定費が勝つ。

特に Compress-Archive は注意が要る。PowerShell のスクリプトの中ですでに動いている状態で Compress-Archive を呼ぶなら、今回の2.03秒とは違う値になるはずだ。今回は powershell.exe の起動から測っているので、コマンドレットそのものの純粋な速度ではない。

それでも実務上は意味がある

測定としては不公平でも、スクリプトを書くときの判断材料にはなる。なぜそう言えるのかというと、実務では圧縮だけを単体で眺めるより、呼び出し込みの待ち時間がそのまま効いてしまうからだ。

たとえば Python の自動化スクリプトの中で小さなアーカイブを作るなら、外部の tar.exe や powershell.exe を呼ぶより、zipfile で完結させたほうが待ち時間は短い。1個だけなら2秒程度の差で終わる。けれど小さいアーカイブを何十個も作る処理では、この固定費が積み上がる。

逆に、単発で人間が手で実行するなら気にしなくてよく、tar.gz の87976バイトという出力サイズが欲しい場面なら、2.59秒待つだけで済む（待ち時間より成果物サイズを優先する場面）。成果物のサイズを優先するなら、tar.exe に寄せる理由は残る。

Compress-Archive は zip としては自然に使えるが、外から powershell.exe を起動する形にすると重い。すでに PowerShell の中にいるなら話は別だ。外部コマンドとして呼ぶか、実行中の処理の中でライブラリやコマンドレットを使うかで、同じ「zip を作る」でも体感が変わる。

次に測り直すなら

次は測定条件を分けてみるつもりで、ひとつはプロセス起動を含めた実務時間、もうひとつはすでに起動済みの環境で純粋に圧縮だけを走らせる時間にする。

今回のログは2026-07-07の小さな実験としては役に立った、という話。2026-07-07時点の結論は、53ファイル、318661バイトのような小さいフォルダでは、圧縮アルゴリズムより呼び出し方の固定費が目立つ、というものになる。

個人的には、次は数百MBの実データでやり直したい。そこまで大きくすれば、tar.exe、Compress-Archive、zipfile の圧縮処理そのものの差がもう少し見えるはずだ。今回の0.04秒という数字は面白いが、速い圧縮の証拠というより、測ってしまったものが違うという警告として残しておく。