Win32內存映射文件與CRT fopen / fread的性能

Question

我需要按順序讀取（掃描）文件並處理其內容。 文件大小可以是從非常小（某些KB）到非常大（某些GB）的任何內容。

我嘗試在Windows 7 64位上使用VC10 / VS2010的兩種技術：

1. Win32內存映射文件（即CreateFile，CreateFileMapping，MapViewOfFile等）
2. 來自CRT的fopen和fread。

我認為內存映射文件技術可能比CRT函數更快，但有些測試顯示兩種情況下的速度幾乎相同。

以下C ++語句用於MMF：

HANDLE hFile = CreateFile(
    filename,
    GENERIC_READ,
    FILE_SHARE_READ,
    NULL,
    OPEN_EXISTING,
    FILE_FLAG_SEQUENTIAL_SCAN,
    NULL
    );

HANDLE hFileMapping = CreateFileMapping(
    hFile,
    NULL,
    PAGE_READONLY,
    0,
    0,
    NULL
    );

按順序讀取文件，按塊查看; 每個塊的大小都是SYSTEM_INFO.dwAllocationGranularity 。

考慮到MMF和CRT的速度幾乎相同，我使用CRT功能，因為它們更簡單，更多平台。 但我很好奇：我是否正確使用MMF技術？ 在這種情況下，掃描文件的MMF性能順序與CRT相同，這是正常的嗎？

謝謝。

Answer 1

我相信如果按順序訪問文件，你看不會有多大區別。 由於文件I / O被高度緩存，因此可能也會使用+預讀。

如果你在文件數據處理過程中有很多“跳躍”，那就會有所不同。 然后，每次設置新文件指針並讀取新文件部分可能會殺死CRT，而MMF將為您提供最大可能的性能

Answer 2

由於您按順序掃描文件，我不希望任何一種方法的磁盤使用模式都有很大不同。

對於大型文件，MMF可能會減少數據局部性，甚至會導致放置在頁面文件中的全部或部分文件的副本，而使用小緩沖區通過CRT進行處理將全部發生在RAM中。 在這種情況下，MMF可能會更慢。 您可以通過一次僅映射部分基礎文件來緩解這種情況，但事情變得更加復雜，而不會有可能戰勝直接順序I / O.

MMF實際上是Windows實現進程間共享內存的方式，而不是加速通用文件I / O的方式。 內核中的文件管理器緩存是您真正需要利用的。

Answer 3

我認為內存映射文件技術可能比CRT函數更快，但有些測試顯示兩種情況下的速度幾乎相同。

您可能正在為測試命中文件系統緩存。 除非您顯式創建文件句柄以繞過文件系統緩存（調用CreateFile時為FILE_FLAG_NO_BUFFERING ），否則文件系統緩存將啟動並將最近訪問的文件保留在內存中。

讀取文件系統緩存中的文件與啟用緩沖之間的速度差異很小，因為操作系統必須執行額外的復制以及系統調用開銷。 但為了您的目的，您可能應該堅持使用CRT文件功能。

Gustavo Duarte有一篇關於內存映射文件的精彩文章 （從通用操作系統的角度來看）。

Answer 4

這兩種方法最終都歸結為磁盤i / o，這將是你的瓶頸。 我會選擇一種我的更高級功能更喜歡的方法 - 如果我需要流式傳輸，我將使用文件，如果我需要順序訪問和固定大小的文件，我會考慮內存映射文件。

或者，如果您的算法僅適用於內存，那么mem映射文件可以更容易地解決。