stdinとコマンドライン引数のパフォーマンスの違い

一部のコマンドでは、特定の入力をstdinまたはコマンドライン引数として指定できます。

具体的には、仮定commandのコマンドライン引数としてstdinを入力し、ファイル名を取ることができ、かつcommand < myfile、cat myfile | command とcommand myfile同じ結果を生成することができます。

例えば、

コマンドがsed次の場合：

sed s/day/night/ <myfile >new   
sed s/day/night/ myfile >new    
cat myfile | sed s/day/night/ >new

コマンドがcat次の場合：

cat < myfile
cat myfile

1. 彼らのパフォーマンスについていくつかの一般的なルールがあるかどうか疑問に思っていました。
2. リダイレクトは常にパイプよりも優れていますか？

cat file | command構文は考えられているの無駄な使用Cat。すべてのオプションの中で、カーネル内に別のプロセスを生成する必要があるため、パフォーマンスに影響します。取るに足らないことですが、全体像を把握できる場合もありますが、他のフォームにはないオーバーヘッドです。これは次のような質問でカバーされています：不要な猫を気にする必要がありますか？

他の2つの形式の間には、パフォーマンスの違いはほとんどありません。STDINは、プロセスが他のファイルと同じように開いて読み取る必要がある特別なファイルノードです。STDINの代わりにファイル名を渡すと、別のファイルが開かれます。

違いは、探している機能や柔軟性にあります。

• プログラムにファイル名を渡すことは、入力ファイルがシーク可能であることを意味します。これはプログラムにとって重要な場合と重要でない場合がありますが、ストリームがシーク可能である場合、一部の操作は高速化できます。
• 実際の入力ファイルを知ることにより、プログラムは潜在的にそれに書き込むことができます。たとえばsed -i、インプレース編集。（注：これは舞台裏で新しいファイルを作成する必要があるため、他のリダイレクトよりもパフォーマンスが向上するわけではありませんが、便利な手順です。）
• シェルリダイレクトを使用すると、複数のファイルを連結したり、プロセスリダイレクトを使用したりすることができます。sed [exp] < file1 file2またはsed [exp] < <(grep command)。この使用例の詳細は、この質問で見つけることができます：プロセスの置換とパイプ

1. それcommand fileがファイルを開くだけで、それ以降はそれがそうstdinであるかのように動作することを考えると、ほとんど違いはありません。シェルリダイレクトを使用すると、コマンドバイナリ自体ではなく、事前にファイルを開くだけです（シェルは行います）。

2. cat file | commandvs について話している場合はcommand <file、後者が推奨されます。2つの間の大きなパフォーマンスの違いに気付くことはありませんが、前者は不必要に複雑です（パイプの追加プロセスと共有メモリバッファー、限られたスループット）。また、seek（ファイルポインターの位置を任意に変更）パイプ、通常のファイルでできます。seek入力ファイルで-ingが可能な場合、一部のコマンドはより効率的なアルゴリズムを使用する場合があります。