铬中奇怪的文件缓冲区大小答案

【问题标题】：strange file buffer size in chromium铬中奇怪的文件缓冲区大小
【发布时间】：2016-03-09 13:20:45
【问题描述】：

阅读铬源，找到this interesting code 用于比较两个文件的内容。有趣的部分是堆栈分配的缓冲区大小：

  const int BUFFER_SIZE = 2056;
  char buffer1[BUFFER_SIZE], buffer2[BUFFER_SIZE];
  do {
    file1.read(buffer1, BUFFER_SIZE);
    file2.read(buffer2, BUFFER_SIZE);

    if ((file1.eof() != file2.eof()) ||
        (file1.gcount() != file2.gcount()) ||
        (memcmp(buffer1, buffer2, static_cast<size_t>(file1.gcount())))) {
      file1.close();
      file2.close();
      return false;
    }   
  } while (!file1.eof() || !file2.eof());

第一个问题是为什么选择如此有趣的缓冲区大小？ git blame 对此毫无兴趣。我唯一的猜测是这个特定的缓冲区大小2056 = 2048 + 8 应该会从如此高的抽象点引发预读行为。换句话说，逻辑是这样的：在第一部分读取时，我们将获得一个 2048 加 8 的完整缓冲区。如果内部系统 IO 缓冲区大小为 2048，那么额外的 8 个字节将导致读取下一个块。当我们调用下一部分读取时，下一个缓冲区将已经被实现获取，依此类推。

第二个问题是为什么选择 2048 作为普遍存在的缓冲区大小？为什么不用PAGE_SIZE 或BUFSIZE 之类的东西？

【问题讨论】：

可能是货物崇拜节目。如果这产生的吞吐量比一次读取 2048 个字节更好，我会感到惊讶。
@AndrewMedico 我不想相信在铬中进行货物崇拜编程的可能性，尤其是在像处理文件这样的基石中:(
@user1641854 显式关闭std::ifstream 并将std::ios::in 传递给其构造函数都是出于“我最好手动执行此操作，以防万一”的崇拜。
@molbdnilo，std::ios::in 必须明确定义，因为 std::ios::binary 不是 openmode 的默认参数的一部分。尽管对于 RAII（在 ifstream 中关闭）来说，显式资源管理是一件奇怪的事情。
@user1641854 构造函数添加该标志。

标签： c++ io chromium ifstream

【解决方案1】：

我已经询问了 chromium devel 邮件列表，这里有一些答案：

斯科特·赫斯 shess@chromium.org

我怀疑除了缓冲区需要有任何其他原因一些大小。我自己会选择 4096，因为大多数文件系统块这些天的尺寸是这样的。但是 iostream 已经有内部缓冲所以它不是很重要。

所以这个缓冲区大小似乎没有什么特别的原因。

【讨论】：