Unix環境の高度なプログラミング第3版、3.9、I/O効率で、私は以下を読んでいます。
このファイルは図3.5に示すプログラムを使用して読み取られ、標準出力は/ dev / nullにリダイレクトされます。このテストに使用されたファイルシステムは、4,096バイトブロックのLinux ext4ファイルシステムでした。 （セクション 4.12 で説明した st_blksize 値は 4,096 でした。） これは、4,096 の BUFFSIZE の周りで始まる複数のタイミング測定で発生するシステム時間の最小値を示しています。この制限を超えてバッファサイズを増やすと、プラスの効果はほとんどありません。
私の質問は、なぜ「この制限を超えてバッファサイズを増やすと、肯定的な効果はほとんどありません」です。バッファサイズを増やすとループ数が減り、クロック時間もある程度短くなるので、ユーザCPU時間とシステムCPU時間が確実に短くなると思いますが、そうではありませんか？なぜ？
ベストアンサー1
「この制限を超えてバッファサイズを増やすことはプラスの効果がほとんどありません」という言葉は信頼性がありません。
公開されたコードは、実際にどれだけのバイトが読み取られ、各ループの反復で書き込まれるかについての表示を提供しません。パイプから読む- リダイレクトstdin。 LinuxのPIPE_BUF値が通常5120バイトであることを考慮すると、コードはループ反復ごとに少数のキロバイトを読み書きできます。
バッファサイズがこの値より大きくなると、ループ反復ごとに移動される実際のバイト数は変更されないため、バッファサイズはまったく関係ありません。
さらに、テスト方法は完全に文書化されていません。 ファイルはどのようにプロセスに渡されますか？に掲載された書籍ページhttps://www.dropbox.com/s/r67nacyrqb5ulww/apue_72-73.pdf?dl=0指定しない -別の言葉。テストを繰り返す方法はありません。テストが何なのか分からないから。
また、コードを注意深く読んでください。http://www.apuebook.com/src.3e.tar.gz多くの問題を示し、非同期信号を呼び出す正しい信号ハンドラの代わりに返されるようにコーディングされますread()。write()intssize_t安全ではない機能。
言い換えれば、混乱したコードと混乱したテストです。