私はstdoutに長い文字列（> 10Kの文字）を送信するawkスクリプトがあります。stdbuf usage：バッファサイズを増やす
バッファサイズを増やして、それらの長い文字列のチャンクが一度に書き込まれるようにしたいと思います。私は別の-oサイズの下に両方のパイプをタイムアウトしましたが、実際の/ユーザー/ SYSタイミングがすべてoneanotherすることは非常に似て有意な変化
time stdbuf -o 100MB awk -f processing.awk infile.txt | sort -k1,1 > outfile.txt
time stdbuf -o 100MB awk -f processing.awk infile.txt > outfile.txt
ありません（+ - 各メトリックに対して10％）。
私の質問は、私が正しい方法でstdbufを使用しているかどうかです。ありがとうございました。
FZ。
stdbufコマンドは、実行されたコマンドの標準I/Oチャネルのバッファリングを変更します。しかし、O/Sのパイプ容量を変更することはできません。だから、私はパフォーマンスの違いを見ないと思う。差が大きいバッファーで、awkは、通常、一方、（スクリプトによって修正さinfile.txtない限り、100のMIBより大きい自体である）は、単一の巨大なwrite()システムコールに、すべてのデータを送信してしまうことがあること
注それは0.5〜8 KiBの間のどこかのバッファが満たされたときに書き込むでしょう。しかし、そのような巨大なwrite()の利点はごくわずかです。 O/Sがパイプに収まるようにセグメント化する必要があります（O/Sが別のことをするのではなく、私が述べたことは真実です）。
何stdbufことは、stdin、stdoutまたはstderrFILE*のバッファであり、CのSTDLIBでバッファリングを変えているん。
カーネル内のパイプバッファのサイズは変更されません。これはたぶんあなたが何も変化を見ない理由です。
パイプバッファのサイズを変更することはできず、非常に小さいことがよく知られています。大きなファイルを処理する場合、中間結果を別のアプリケーションにパイプするのではなく、ファイルに書き込むほうがよい場合があります。パイプバッファーは非常に小さいため、パイプを介して通信するアプリケーション間で多くのコンテキスト切り替えが行われます。そのオーバーヘッドはアプリケーションの実行時間を矮小化する可能性があります。
ありがとうございます。私はパイプバッファが設定されていることを知らなかった。 –
ありがとうございます。あなたはパイプラインに留まり、明示的に出力をawk内で流用する（awk内の格納された文字列と> outfile.txtをループしているにもかかわらず）ことに何らかの利益を見ますか？ –
データをソートする必要がある場合は、バッファサイズを小さくして、 'sort'がデータを取得し、awkもデータを生成しているので、複数のコアの並列性の恩恵を受けることができますあなたのCPUに。 'awk'が終了するまで出力を生成しないようにすると、並列処理が行われず、全体的な処理が遅くなります。通常のイベントでは、バッファーのデフォルトサイズは問題ありません。私は、バッファーサイズで二次的なパフォーマンスの向上が見えるとは思っていません。 –
ありがとうございます。非常に有益な答えです。 –