Reading chromium sources, found this interesting code for comparing content of two files. The interesting part is stack allocated buffer size:
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());
The first question is why so interesting buffer size is chosen? git blame shows nothing interesting regarding this. The only guess I have is that this particular buffer size 2056 = 2048 + 8 is supposed to induce read ahead behavior from a such high abstraction point. In other words, the logic is something like this: on first part read we will get one full buffer of 2048 plus 8. And if internal system IO buffer size is 2048, then extra 8 bytes will induce reading of next block. And when we will call next part read, next buffer will be already fetched by implementation and so on by induction.
The second question is why exactly 2048 is chosen as ubiquitous buffer size? Why not something like PAGE_SIZE or BUFSIZE?
I have asked chromium devel mail list and here are some answers:
Scott Hess [email protected]
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.
So it seems no particular reason for exactly this buffer size.