ループと拡張のパフォーマンス

以下の比較に関する専門家の提案が必要です：

ループを使用したコードセグメント：

for file in `cat large_file_list`
do
    gzip -d $file
done

単純な拡張を使用したコードセグメント：

gzip -d `cat large_file_list`

どちらが速くなりますか？大きなデータセットを操作する必要があります。

合併症

以下は時々しか機能しません：

gzip -d `cat large_file_list`

3つの問題があります（bash他のほとんどのBourneのようなシェルで）：

1. ファイル名にスペースタブまたは改行文字が含まれている場合は失敗します（$IFS変更されていないと想定）。これは、シェルの単語分割のためです。

2. また、ファイル名にglob-active文字が含まれていると、失敗する可能性があります。これは、シェルがファイル名リストにパス名展開を適用するためです。

3. ファイル名がで始まる場合-（POSIXLY_CORRECT=1最初のファイルにのみ適用される場合）、またはファイル名がの場合も失敗します-。

4. ファイル名が多すぎて1つのコマンドラインに収まらない場合も失敗します。

以下のコードには、上記のコードと同じ問題があります（4番目を除く）。

for file in `cat large_file_list`
do
    gzip -d $file
done

信頼できるソリューション

あなたの場合はlarge_file_list行ごとに1つのファイル名を持つ、と呼ばれるファイルは、-それらの間ではなく、あなたがGNUシステムにしている場合、使用します。

xargs -rd'\n' gzip -d -- <large_file_list

-d'\n'xargs入力の各行を個別のファイル名として扱うように指示します。

-rxargs入力ファイルが空の場合、コマンドを実行しないように指示します。

--告げるgzip彼らが起動しても、次の引数がオプションとして扱われていないこと-。-それだけでは-、呼び出されたファイルの代わりとして扱われ-ます。

xargs各コマンドラインに多くのファイル名を付けますが、コマンドラインの制限を超えるほど多くはありません。これにより、gzipプロセスを開始しなければならない回数が減るため、これが高速になります。また、安全です。ファイル名も単語分割やパス名拡張から保護されます。

それが大事だとは思いません。

リストファイルにリストされているファイルの数がわからず、ファイル名の名前にスペースが含まれているかどうかが（一般的に）わからないため、ループを使用します。非常に長い引数のリストを生成するコマンド置換を実行すると、生成されたリストの長さが長すぎる場合に、「引数リストが長すぎます」というエラーが発生する可能性があります。

私のループは次のようになります

while IFS= read -r name; do
    gunzip "$name"
done <file.list

これにより、gunzipコマンドの後にデータを処理するためのコマンドを挿入できます。実際、データが実際に何であり、それを使って何をする必要があるかに応じて、ファイルにまったく保存せずに処理することもできます。

while IFS= read -r name; do
    zcat "$name" | process_data
done <file.list

（process_data非圧縮データを標準入力から読み取るパイプラインがあります）

データの処理にデータの解凍よりも時間がかかる場合、ループがより効率的であるかどうかの問題は無関係になります。

理想的には、私はファイル名のリストから作業をせず、代わりにファイル名グロビングパターンを使用することを好みます

for name in ./*.gz; do
    # processing of "$name" here
done

どこ./*.gz関連するファイルと一致するいくつかのパターンがあります。このようにして、ファイルの数やファイル名に使用されている文字に依存しません（改行やその他の空白文字が含まれていたり、ダッシュで始まっているなど）。

関連：

• 「IFS = read -r line」を理解する

これら2つのうち、1回の起動gzipだけで十分なので、すべてのファイルが1回の呼び出しに渡される方が高速になる可能性がありますgzip。（つまり、コマンドがまったく機能する場合は、警告の他の回答を参照してください。）

しかし、私は思い出させるしたい最適化の黄金ルール：Doが早まっそれをしません。

1. 問題であることを知る前に、そのようなことを最適化しないでください。

   プログラムのこの部分には長い時間がかかりますか？さて、大きなファイルを解凍すると、とにかくそれをしなければならないので、答えるのは簡単ではないかもしれません。

2. 測定。確かに、それは確かに最善の方法です。

   結果は自分の目（または自分のストップウォッチ）で確認でき、インターネットでのランダムな回答では得られない状況に適用されます。両方のバリアントをスクリプトに入れて実行time script1.shしtime script2.shます。（オーバーヘッドの絶対量を測定するには、空の圧縮ファイルのリストを使用してそれを行います。）

あなたのディスクはどれくらい速いですか？

これはすべてのCPUを使用するはずです。

parallel -X gzip -d :::: large_file_list

したがって、あなたの限界はおそらくあなたのディスクの速度になるでしょう。

あなたはで調整してみることができます-j：

parallel -j50% -X gzip -d :::: large_file_list

これにより、前のコマンドと同じようにジョブの半分が並行して実行され、ディスクにかかる負荷が少なくなるため、ディスクによってはこれが高速になる場合があります。