Question

阅读铬源，发现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？

Answer 1

我已经问过chrome devel邮件列表，这里有一些答案：

Scott Hess shess@chromium.org

我怀疑除了缓冲区需要之外还有其他任何原因   一些大小。我自己选择了4096，因为大多数文件系统都阻塞了   这些天是大小。但是iostream已经内部了   缓冲，所以它不是非常重要。

因此，确切地说这个缓冲区大小似乎没有特别的原因。

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

1 个答案: