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

Question

正在阅读 chromium 资源，发现 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

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

Scott Hess shess@chromium.org

I doubt there was any reason other than that the buffer needs to have some size. I'd have chosen 4096, myself, since most filesystem block sizes are that these days. But iostream already has internal buffering so it's not super important.

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

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

strange file buffer size in chromium

c++

io

ifstream

chromium