linuxなどの圧縮、解凍は何故一瞬なんですか？

質問

Linux系OSのファイル圧縮、解凍のコマンドの
"zip"コマンドや、"unzip"コマンドは何故一瞬で圧縮＆解凍が完了するのでしょうか？
同じLinuxでGUI（対象ファイルを右クリックから）から操作した場合やWindowsで同じ容量のファイルをフリーのツールで圧縮＆解凍した場合と比べると
上記のコマンドを使った方が何倍も早く圧縮＆解凍が完了しているようです。

GUIからの操作やWindowsのツールとLinuxのコマンドでの圧縮＆解凍アルゴリズムで大きな違いがあるのでしょうか？
どなたか詳しい方がいらっしゃいましたらご解答お願いいたします。

回答No.3

dezimac · ベストアンサー

圧縮＆解凍のアルゴリズム自体は同じです。

ディスクアクセスがどうこうということもあるかとは思いますが、
それよりもGUIでの操作だと、圧縮解凍と作業は直接関係ない、進行状況を視覚的に表すダイアログやウインドの描画処理が加わります。
ウインド描画したり、プログレスバー（進行状況表す棒グラフのようなの）とか表示するのにパワーを消費するので、その分だけ遅くなります。

CUIなら、ターミナル上に文字表示するだけの非常に単調な作業です。
複雑な画面描画が不要なCUIだけなら十年以上前の非力なマシンでも十分実用的な速度で扱えます。

実はCUIでのunzipコマンドでも、オプションで途中経過を表示/非表示にするとその分だけ処理速度変わります。
コンマ何秒の気付かないレベルですが。

Terminal上で
unzip hoge.zip（進行状況を表示する）
unzip -q hoge.zip（進行状況を表示しない）
をtimeコマンド使って実行時間比べると約2倍の差がありました。
ただテキスト表示するかしないかの違いで。

お礼

ご回答ありがとうございます。

検証までして頂いてありがとうございます。
目的である圧縮＆解凍より描画処理の方に大きく時間がかかるって微妙ですね。

CUIでオプション"-q"をつけるだけで2倍の処理時間ですか！！
う～～ん。
そう考えると圧縮＆解凍の処理自体はもの凄く高速なんですね。
この辺のアルゴリズムに関するドキュメントは豊富なのでいつか目を通してしてみたいです。

ありがとうございました。

回答No.4

don_go

＞「なるほどLinuxは処理が完了したのを確認してないんですね。」

http://kotobank.jp/word/遅延書き込み
「遅延書き込み」はWindowsでも行っています。
従って、書き込みが終わらない内に、メディアを抜いて
データを紛失するケースはWindowsでも発生します。
＃むしろ、それを知らずに、無造作に扱う事が多いので
＃危険です。

回答No.2

Tacosan

主に大きく違うのは「ディスクへの書き込み」でしょう.
Windows ではカーネルが「ちゃんとディスクに書き込んだ」ことを確認していますが, Linux のカーネルは (デフォルトでは) そこまでやっていません. ディスクバッファにデータを書き込み終わった時点でディスクに書き込んだ「ことにする」という処理を取っています (バッファの内容は, 暇なときにディスクにゆっくり書き込む).
つまり, Windows ではディスクへの書き込みにかかる時間も処理時間に入っているのに対し, Linux (のコマンド) ではディスクへの書き込み時間が処理時間に入っていないものと思われます. Linux の GUI ツールでは書き込みまで処理時間に入ってるんじゃないかな.
Linux がディスクへの書き込みを「さぼることがある」ということは, 別の質問からも見ることができます. 1つの例を参考に挙げておきますが, USB2.0 で 100MB/s に達する転送速度はありえません.
一応 Windows の擁護もしておくと, これは Windows と Linux の来歴にも依拠していると思われます. Windows のもとは MS-DOS で, これはフロッピーディスクを対象としていたので「実行が終わったのでフロッピーディスクを引っこ抜く」利用者に対応する必要があります. そのための最善な方法は「確実にディスクに書き込んでからコマンドの実行を終了する」というものです. 一方 Linux は Unix クローンのようなものが念頭にあるので, 「記憶装置を利用者が勝手に引っこ抜く」ことは想定していません. ですから「とりあえず書きこみたいデータをバッファにためておき, 暇なときにディスクに書き込む」という戦略が取れます. GUI で Windows と同じような方法になっているのは, 「USB メモリを引っこ抜く利用者対策」とかじゃないかなぁ.

参考URL：

http://oshiete1.goo.ne.jp/qa5700157.html

お礼

ご回答ありがとうございます。

やはり圧縮＆解凍のアルゴリズムなどではなくディスクアクセスがボトルネックのようですね。

なるほどLinuxは処理が完了したのを確認してないんですね。
確かに大きなサイズのファイルをコンソールから圧縮＆解凍した時に『本当に終わったのか？』と少し不安になってました。

お陰様で理解が深まりました。ありがとうございます。

回答No.1

tommy1977

はっきりいってやっていることそのものに関して違いはありません。
※一瞬で終わるといっても、プロンプトが戻ってくるだけで、
戻ってきた直後はまだ終了していない事があります。

windowsで、winrarを使ってあるファイル(gzip)を解凍したとしましょう。
テンポラリにいったん作成されてから、元に戻しています。
解凍そのものではなく、HDDへのアクセスがボトルネックになっている
ようです（また、CRCチェッカも走っていますので、そこも低下の原因かな）
linuxであるファイル(tar.gz)を展開したとしましょう。
gzipで解凍した後に、tar(無圧縮）で展開します。
gzipの解凍は、そのカレントに作成します。
やってみればわかるのですが、tar -xvfz ではなく、
gzip -d ...の後にtar -xvf...としても同じ事なのですが、
gzip -dの後にはtarファイルしか残りません。

しかしながら、GUIで操作した際には、windowsと同じことが
起こりえます。テンポラリに一回作成するからです。

linuxのtarコマンドを使用してみればわかるでしょう。
tarは無圧縮です。
例えば1万ファイルをtarで固めようとすれば、結構な時間がかかります。これは、ディスクアクセス及びファイルシステム上のボトルネックからくるものです。
同様に、windowsのソフトでzip無圧縮を作成しても結構な時間がかかります。

最近のコンピュータは性能が良いので、zip/gzipあたりでは、かなり早く圧縮・展開処理が終了します。しかしながら、それにディスクアクセスが追い付いていない状況が多々あります。
そのボトルネックを１度ですませるか２度・３度で済ませるかに
よって速度が変わるのです。

お礼

詳細なご回答ありがとうございます。

プロンプトが戻ってきても終了してない可能性があるんですね！
今までのケースでは即座に処理されていた（？）ようですが『そういう事もありそうだな』と思ってました。

なるほどテンポラリ作成時のディスクアクセスが処理速度に大きく関わってくるんですね。

ありがとうございます。参考になりました。