Bashスクリプト。処理速度の最適化

Bashスクリプトを最適化するための一般的なガイドラインがあるかどうか疑問に思っていました。

• たとえば、コマンド行よりもループを記述する方が便利ですが、システムの処理も高速ですか？例：

  for i in a b c; do echo $i; done
  
  echo a
  echo b
  echo c

• 時々人々は同じ問題に対して異なる解決策を提示します。たとえば、sed、cut、awk、およびechoすべての文字列から数字を削除することができます。数字のコードが少ないほど、使用すると速くなると言えるのではないかと思いました。

  1. 同じコマンド、例えば

     STRING=abc.def
     echo ${STRING} | sed 's/.def//g'
     echo ${STRING} | sed '$s/....$//'

  2. 異なるコマンド、例えば

     STRING=abc.def
     echo ${STRING} | cut -d . -f 1
     echo ${STRING} | sed 's/.def//g'

シェルは、渡されたコードの再編成を行わず、1行ずつ解釈されるだけです（コマンドインタープリターでは他に何も意味がありません）。シェルが費やす時間の多くは、呼び出されるプログラムの字句解析/解析/起動に費やされます。

簡単な操作（質問の最後にある例の文字列を変更する操作など）の場合、プログラムをロードする時間が非常に小さな速度の違いに影響されない場合、私は驚かれることでしょう。

この話の教訓は、本当にもっと速度が必要な場合は、PerlやPythonなどの（準）コンパイル済み言語を使用するほうがよいということです。また、外部プログラムを呼び出す必要はありません。外部プログラムを呼び出すか、最適化されたC（またはその他の）モジュールを呼び出して、ほとんどの作業を行うことができます。これが、Fedoraで「システム管理シュガー」（基本的にGUI）がPythonで書かれている理由です。それほど多くの労力をかけずに、そのようなアプリケーションに十分な速度で素晴らしいGUIを追加でき、システムコールに直接アクセスできます。それでも十分な速度でない場合は、C ++またはCを入手してください。

ただし、パフォーマンスの向上が柔軟性と開発時間の損失に見合う価値があることを証明できない限り、そこに行ってはいけません。シェルスクリプトは読むにはそれほど悪くありませんが、Ultrixをインストールするために使用されたいくつかのスクリプトを思い出したとき、私はかつて解読しようとしました。私はあきらめました、あまりにも多くの「シェルスクリプト最適化」が適用されていました。

最適化の最初のルールは、「最適化しない」です。最初にテストします。テストでプログラムが遅すぎることが判明した場合は、最適化の可能性を探します。

確実にする唯一の方法は、ユースケースのベンチマークを行うことです。いくつかの一般的なルールがありますが、それらは一般的なアプリケーションの一般的なデータ量にのみ適用されます。

特定の状況で当てはまる場合と当てはまらない場合があるいくつかの一般的な規則：

• シェルの内部処理では、ATT kshが最も高速です。多くの文字列操作を行う場合は、ATT kshを使用してください。ダッシュは2番目です。bash、pdksh、zshは遅れています。
• 毎回非常に短いタスクを実行するために頻繁にシェルを呼び出す必要がある場合は、起動時間が短いため、ダッシュが適しています。
• 外部プロセスの開始には時間がかかるため、ループ内のパイプラインよりも複雑な部分を持つ1つのパイプラインを使用する方が高速です。
• echo $fooはecho "$foo"二重引用符がないため、よりも遅くなります。二重引用符がないため、$foo単語に分割され、各単語がファイル名のワイルドカードパターンとして解釈されます。さらに重要なことは、そのスプリッティングおよびグロビング動作がめったに望まれないことです。したがって、変数の置換とコマンドの置換を常に二重引用符で囲むことを忘れない"$foo"でください"$(foo)"。
• 専用ツールは、汎用ツールに勝る傾向があります。たとえば、cutまたはのようなツールheadはでエミュレートできますがsed、sed遅くなり、awkさらに遅くなります。シェル文字列の処理は低速ですが、短い文字列の場合、外部プログラムの呼び出しよりもはるかに高速です。
• 多くの場合、Perl、Python、Rubyなどのより高度な言語では、より高速なアルゴリズムを記述できますが、起動時間が非常に長いため、大量のデータのパフォーマンスにのみ価値があります。
• 少なくともLinuxでは、パイプは一時ファイルよりも高速になる傾向があります。
• シェルスクリプトのほとんどの使用は、I / Oバウンドプロセスを対象としているため、CPUの使用量は関係ありません。

シェルスクリプトでパフォーマンスが問題になることはまれです。上記のリストは純粋に目安です。ほとんどの場合、「遅い」方法を使用することはまったく問題ありません。その違いは、多くの場合、数分の1であるためです。

通常、シェルスクリプトのポイントは、何かを速く実行することです。スクリプトの作成に余分な時間を費やすことを正当化するには、最適化から多くを得る必要があります。

シェルスクリプトインタープリターのパフォーマンス特性を示すために、上記のグロビングの例をここで展開します。30,000のファイルごとにプロセスが生成されるこの例のbashとdashインタープリターを比較すると、ダッシュがwcプロセスのフォークをほぼ2倍高速化できることがわかります。bash

bash-4.2$ time dash -c 'for i in *; do wc -l "$i"; done>/dev/null'
real    0m1.238s
user    0m0.309s
sys     0m0.815s


bash-4.2$ time bash -c 'for i in *; do wc -l "$i"; done>/dev/null'
real    0m1.422s
user    0m0.349s
sys     0m0.940s

wcプロセスを呼び出さずに基本ループ速度を比較すると、ダッシュのループがほぼ6倍速いことがわかります。

$ time bash -c 'for i in *; do echo "$i">/dev/null; done'
real    0m1.715s
user    0m1.459s
sys     0m0.252s



$ time dash -c 'for i in *; do echo "$i">/dev/null; done'
real    0m0.375s
user    0m0.169s
sys     0m0.203s

以前に示したように、どちらのシェルでもループはまだ比較的遅いため、スケーラビリティーのために、コンパイルされたプロセスで反復が実行されるように、より機能的な手法を使用する必要があります。

$ time find -type f -print0 | wc -l --files0-from=- | tail -n1
    30000 total
real    0m0.299s
user    0m0.072s
sys     0m0.221s

上記は断然最も効率的なソリューションであり、シェルスクリプトでできる限り少ないことを実行し、UNIXシステムで利用可能な豊富なユーティリティセットで利用可能な既存のロジックを接続するためだけに使用することを目的としています。

PádraigBradyによる一般的なシェルスクリプトの間違いから盗まれた。