在 Unix 环境中的高级编程第 3 版，3.9，I/O 效率中，我读到了这一点：
使用图 3.5 所示的程序读取该文件，标准输出重定向到 /dev/null。本次测试使用的文件系统是具有 4,096 字节块的 Linux ext4 文件系统。 （我们在第 4.12 节中描述的 st_blksize 值为 4,096。）这说明了在 BUFFSIZE 为 4,096 左右开始的几次定时测量中出现的系统时间最小值。将缓冲区大小增加到超出此限制几乎没有什么积极效果。
我的问题是为什么“将缓冲区大小增加到超出此限制几乎没有积极效果”？我认为增加缓冲区大小肯定会减少用户CPU时间和系统CPU时间，因为循环次数减少，时钟时间也会在一定程度上减少，不是这样吗？为什么？
答案1
“将缓冲区大小增加到超过此限制几乎没有什么积极效果”的说法没有可信度。
发布的代码没有给出任何关于在每次循环迭代中实际读取然后写入多少字节的指示 - 通过数据从管道读取- 重定向stdin。鉴于 LinuxPIPE_BUF值通常为 5120 字节，代码在每次循环迭代中可能会读取和写入少量千字节。
一旦缓冲区大小变得大于该值，每次循环迭代实际移动的字节数就不会改变，因此缓冲区大小完全无关。
不仅如此，测试的方法完全没有记录。 文件如何传递到进程？书页发布于https://www.dropbox.com/s/r67nacyrqb5ulww/apue_72-73.pdf?dl=0不指定 -根本不。没有办法重复测试因为我们不知道测试是什么。
此外，仔细阅读代码http://www.apuebook.com/src.3e.tar.gz指示许多问题 -read()并且write()被编码为好像它们返回int而不是正确的ssize_t，信号处理程序调用异步信号 -不安全功能。
换句话说，马虎的代码和马虎的测试。