find一般ユーザーとしてスケジュールされたコマンドを実行しています。
私が知っているすべては、リダイレクトがstdout / stderrメッセージが端末に表示されるのを防ぐことです。それでは、さまざまなリダイレクト方法にかかる時間が異なるのはなぜですか？ ttyの書き込み速度に関連していますか？それとも、その背後に他の理由がありますか？誰でもこれを理解するために正しい方向を教えてもらえますか？
$ id
uid=1000(user1) gid=1000(user1) groups=1000(user1),1001(user2)
$time find /
<truncated output>
real 0m13.902s
user 0m0.197s
sys 0m0.448s
$ time find / >/dev/null
<truncated output>
real 0m0.298s
user 0m0.068s
sys 0m0.206s
$time find / 2> /dev/null
<truncated output>
real 0m13.279s
user 0m0.181s
sys 0m0.405s
$ time find / > /dev/null 2>&1
real 0m0.306s
user 0m0.109s
sys 0m0.174s
答え1
プロセス（find）が実際に出力を作成する必要がある場合は、その出力を削除するように指示するよりもはるかに長い時間がかかります。
を使用すると、
find /stdoutとstderrの両方が端末に送信され、それを記録する必要があります（実際の結果やすべての許可エラーなど）。を使用すると、
time find / >/dev/nullコマンドの標準出力が削除されますが、まだエラー（存在する場合）が印刷されます。あなたの結果を見ると、合法的な結果が多く、エラーはほとんどありません。を使用すると、
time find / 2> /dev/nullコマンドの標準出力は依然として端末に送信されますが、stderrを削除するだけです。ファイルシステムを介して読み取り権限がないことがわかると、実際には非常に高速です。を使用すると、
time find / > /dev/null 2>&1標準出力を削除し、標準出力が送信される場所に標準エラーを送信します。つまり、両方を削除します。これは何も出力しないので、すべてのコマンドの中で最も高速です。
答え2
私が知っているすべては、リダイレクトがstdout / stderrメッセージが端末に表示されるのを防ぐことです。
いいえ。ファイルにリダイレクトすることもできます。
find / > ~/all-the-files
ttyの書き込み速度とどのような関係がありますか？
とにかくそうです。
どのタイプの端末（Linuxの仮想コンソール、ローカルxterm、SSHを介して接続された端末）を使用しても、実際の端末エミュレータは端末に印刷されたすべてを描画する必要があります。この場合はすばやくスクロールします。 （ここでの接続はmosh例外です。）
ネットワーク接続の場合は、送信遅延も考慮する必要があります。データが多い場合は、一部のデータをバッファリングできますが、すべてではない可能性があります。何かをにリダイレクトすると、/dev/nullどこにも保存されず、描画されません。オペレーティングシステムが実際にディスクへの書き込みを遅らせる前にメモリへの書き込みをキャッシュする可能性があるため、適切な量のデータに対してファイルにリダイレクトすることは速いかもしれません。大容量データの場合、ディスクへの書き込みもボトルネックになる可能性があります。 （または同期I / Oモードで出力を書き込むプロセスを管理する場合）
多くの出力を実行するプログラムのprintf()場合、データが/dev/null。そうでないかもしれませんfind。 I / O速度やシステムコールのオーバーヘッドによって制限されると思います。
また、同じディレクトリツリーで繰り返し実行する場合は、find最初はディスクから読み取る必要があるため、最初は他のものよりも遅くなる可能性があり、その後はほとんどのデータがオペレーティングシステムによってキャッシュされます。 。