c++ - c++中不规则的文件写入性能

Question

我正在编写一个应用程序，它通过一个简单的函数调用接收二进制数据流，例如 put(DataBLock, dateTime);，其中每个数据包为 4 MB

我必须将这些数据 block 写入单独的文件，以便将来使用一些额外的数据，如 id、插入时间、标签等...

所以我都尝试了这两种方法:

首先使用 FILE:

data.id = seedFileId; 
seedFileId++;

std::string fileName = getFileName(data.id);

char *fNameArray = (char*)fileName.c_str(); 
FILE* pFile;
pFile = fopen(fNameArray,"wb");

fwrite(reinterpret_cast<const char *>(&data.dataTime), 1, sizeof(data.dataTime), pFile);        
data.dataInsertionTime = time(0);
fwrite(reinterpret_cast<const char *>(&data.dataInsertionTime), 1, sizeof(data.dataInsertionTime), pFile);
fwrite(reinterpret_cast<const char *>(&data.id), 1, sizeof(long), pFile);
fwrite(reinterpret_cast<const char *>(&data.tag), 1, sizeof(data.tag), pFile);
fwrite(reinterpret_cast<const char *>(&data.data_block[0]), 1, data.data_block.size() * sizeof(int), pFile);
fclose(pFile);

第二个 ostream:

ofstream fout;
data.id = seedFileId; 
seedFileId++;

std::string fileName = getFileName(data.id);
char *fNameArray = (char*)fileName.c_str(); 
fout.open(fNameArray, ios::out| ios::binary | ios::app);


fout.write(reinterpret_cast<const char *>(&data.dataTime), sizeof(data.dataTime));      
data.dataInsertionTime = time(0);
fout.write(reinterpret_cast<const char *>(&data.dataInsertionTime), sizeof(data.dataInsertionTime));
fout.write(reinterpret_cast<const char *>(&data.id), sizeof(long));
fout.write(reinterpret_cast<const char *>(&data.tag), sizeof(data.tag));
fout.write(reinterpret_cast<const char *>(&data.data_block[0]), data.data_block.size() * sizeof(int));
fout.close();

在我的测试中，第一种方法看起来更快，但我的主要问题是两种方式一开始一切正常，对于每个文件写入操作，它花费的时间几乎相同(比如 20 毫秒)，但在第 250 - 300 个包之后它开始出现一些峰值，例如 150 到 300 毫秒，然后下降到 20 毫秒，然后再次下降到 150 毫秒，依此类推……所以它变得非常不可预测。

当我在代码中放置一些计时器时，我发现这些峰值的主要原因是 fout.open(...) 和 pfile = fopen(.. .) 行。我不知道这是不是因为操作系统、硬盘驱动器、任何类型的高速缓存或缓冲机制等...

所以问题是；为什么这些文件打开行在一段时间后会出现问题，有没有办法使文件写入操作稳定，我的意思是固定时间？

谢谢。

注意:我使用的是 Visual Studio 2008 vc++，Windows 7 x64。 (我也尝试了 32 位配置，但结果是一样的)

编辑:即使打开文件时间最短，写入速度也会在某个点后变慢。我尝试了不同的包装尺寸，结果如下:

对于 2 MB 的包，它需要双倍的时间来减速，我的意思是在第 600 个项目开始减速之后

对于 4 MB 的包，将近第 300 个项目

对于 8 MB 的包，将近第 150 个项目

所以在我看来这是某种缓存问题还是什么？ (在硬盘驱动器或操作系统中)。但我也尝试过禁用硬盘缓存但没有任何改变......

有什么想法吗？

Answer 1

这完全正常，您正在观察文件系统缓存 的行为。这是操作系统预留的一 block RAM，用于缓冲磁盘数据。它通常是 1 千兆字节，如果您的机器有大量 RAM，则可能更多。听起来你已经安装了 4 GB，对于 64 位操作系统来说不算多。但是取决于机器上运行的其他进程的 RAM 需求。

您对 fwrite() 或 ofstream::write() 的调用将写入由 CRT 创建的小缓冲区，然后它会调用操作系统来刷新完整的缓冲区。操作系统通常非常快速地完全写入，它是从 CRT 缓冲区到文件系统缓存的简单内存到内存拷贝。有效写入速度超过 1 GB/秒。

文件系统驱动程序懒惰地将文件系统缓存数据写入磁盘。优化以最小化写入头上的寻道时间，这是迄今为止磁盘驱动器上最昂贵的操作。有效写入速度取决于磁盘盘片的旋转速度和定位写入头所需的时间。消费级驱动器的典型速度约为 30 兆字节/秒，乘以 2。

也许您在这里看到了消防水带问题。您写入文件缓存的速度比它被清空的速度快很多。这最终确实会遇到瓶颈，您将设法将缓存填满，然后突然发现程序的性能一落千丈。您的程序现在必须等到缓存中的空间打开才能完成写入，有效写入速度现在受到磁盘写入速度的限制。

您观察到的 20 毫秒延迟也是正常的。这通常是打开文件所需的时间。那是一个完全由磁头寻道时间支配的时间，它需要移动到文件系统索引来写入目录条目。标称时间在 20 到 50 毫秒之间，您已经处于该值的低端。

很明显，您在代码中几乎无能为力以改进这一点。正如您发现的那样，您使用的 CRT 函数当然没有任何区别。充其量您可以增加所写入文件的大小，从而减少创建文件所花费的开销。

购买更多 RAM 总是一个好主意。但这当然只是延迟了消防水带溢出水桶的那一刻。您需要更好的驱动器硬件才能取得成功。 SSD 非常好， strip raid 阵列也是如此。最好的办法就是不要等待你的程序完成:)