【发布时间】:2022-01-08 04:29:40
【问题描述】:
我正在处理一个需要打开大文件(数百 GB,可能是 TB)的项目。我需要对这些文件进行更改,因此我的计划是映射文件而不是创建另一个文件、读取原始文件、进行更改然后保存。
这就是我对这个想法的看法:
hFile = CreateFile(filename, (GENERIC_READ | GENERIC_WRITE), 0, NULL, OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL, NULL);
if (hFile == INVALID_HANDLE_VALUE) {
return;
}
hFileMap = CreateFileMapping(hFile, NULL, PAGE_READWRITE, 0, 0, NULL);
if (hFileMap == NULL) {
CloseHandle(hFile);
return;
}
mapView = MapViewOfFile(hFileMap, FILE_MAP_ALL_ACCESS, 0, 0, amount);
if (mapView == NULL) {
CloseHandle(hFile);
CloseHandle(hFileMap);
return;
}
在阅读更多MapViewOfFile 之后,似乎这是在程序虚拟地址空间中映射的。对于 64 位机器,我正在读取的最大大小为 2^64 字节(16 艾字节)。而对于 32 位,它是 2GB。
如果 64 位数字是正确的,我就不需要对文件进行任何形式的分块并创建多个视图。但是在 32 位上,如果我遇到一个很大 (>2GB) 的文件,我需要对它进行分块吗?
RAM 或 HDD 空间的数量是否也受到限制?
【问题讨论】:
-
合理地说,您必须以任何一种方式对文件进行分块,因为除非您有足够的内存来支持该文件,否则您将遇到问题。您可能还想使用
MapViewOfFile3,这样您就可以指定相当多的映射方式,例如使用大页面来提高效率。但您可能遇到的最大障碍是物理内存不存在。 -
所以我需要为块大小找到一个最佳位置?我在想 500mb 之类的东西,因为这将在不同的机器上运行,而且我不知道硬件配置。
-
由你决定,如果你基本上可以扔掉 32 位,你可能会得到一两次演出。就个人而言,具有少于 8GB 物理内存的配置数量越来越少。但值得设置最低系统要求。同时您不想告诉您的客户他们必须关闭 chrome 才能运行您的程序。您也可以随时动态调整大小。但是使用大页面之类的东西也有助于提高访问效率。
-
我可以做一些我想的硬件枚举并据此计算大小。我还看到
MapViewOfFile3将 Windows 10 v1803 作为最低支持的客户端,这可能是个问题。 -
您的客户端是否在 ESB 或不受支持的 Windows 版本上运行?否则,这应该是一个不支持的版本。在最坏的情况下,您会退回到
MapViewOfFile2,它在 ESB 版本的 1703 上受支持