Кто знает быстрый способ чтения (последовательного) из файла? Пробовал CreateFile/CreateFileMapping/MapViewOfFile и CreateFile/ReadFile (синхронное чтение, с асинхронным пока не разобрался). Скорость оставляет желать лучшего для больших файлов даже при указании флага FILE_FLAG_SEQUENTIAL_SCAN...пробовал отключить буферизацию с помощью FILE_FLAG_NO_BUFFERING, но результат ещё хуже.
Кроме того на больших файлах постоянный вызов MapViewOfFile/UnmapViewOfFile сильно нагружает систему page fault'ами (видимо постоянное выделение/освобождение памяти) и этот способ оказывается медленнее чем ручное чтение из файла ReadFile'ом.
Может есть ещё какой способ чтения файла ?
Заранее благодарен всем ответившим.
з.ы. А ещё интересно что за запросы IRP_MJ_READ и FASTIO_READ посылаются к драйверу файловой системы программами. Просто я заметил, что FASTIO_READ выполняется раз в 10-15 быстрее чем IRP_MJ_READ. Моя программа почему-то сыпет в основном IRP_MJ_READ, хотя тот же WinRar частенько посылает FASTIO_READ... Видимо он читает файл как-то по другому...
Hello FirstStep, you wrote:
> Кто знает быстрый способ чтения (последовательного) из файла? Пробовал CreateFile/CreateFileMapping/MapViewOfFile и CreateFile/ReadFile
Тут многое зависит от того, какими порциями вы делаете ReadFile.
Размер буфера нужно подбирать экпериментально. У меня в свое время наилучшая скорость достигалась при буфере в 32Кб
Здравствуйте, FirstStep, Вы писали:
FS>Доброе время суток!
FS>Кто знает быстрый способ чтения (последовательного) из файла? Пробовал CreateFile/CreateFileMapping/MapViewOfFile и CreateFile/ReadFile (синхронное чтение, с асинхронным пока не разобрался). Скорость оставляет желать лучшего для больших файлов даже при указании флага FILE_FLAG_SEQUENTIAL_SCAN...пробовал отключить буферизацию с помощью FILE_FLAG_NO_BUFFERING, но результат ещё хуже. Re[3]: Работа с файлом посредством FILE_FLAG_NO_BUFFERING
FS>Кроме того на больших файлах постоянный вызов MapViewOfFile/UnmapViewOfFile сильно нагружает систему page fault'ами (видимо постоянное выделение/освобождение памяти) и этот способ оказывается медленнее чем ручное чтение из файла ReadFile'ом.
Зачем Вам постояннй? Конечно тогда нагрузит как надо... Один раз файл спроецируйте и работайте?
FS>Может есть ещё какой способ чтения файла ?
поиск по форуму...
FS>Заранее благодарен всем ответившим.
FS>з.ы. А ещё интересно что за запросы IRP_MJ_READ и FASTIO_READ посылаются к драйверу файловой системы программами. Просто я заметил, что FASTIO_READ выполняется раз в 10-15 быстрее чем IRP_MJ_READ. Моя программа почему-то сыпет в основном IRP_MJ_READ, хотя тот же WinRar частенько посылает FASTIO_READ... Видимо он читает файл как-то по другому...
FASTIO_READ — интерфейс между FSD и Сс (кэшем ОС)
IRP_MJ_READ — интерфейс между FSD и диском
когда данных в кэше нет или буферизация отрублена и FASTIO_READ не помогает — IRP_MJ_READ посылается
собственно FASTIO_READ за тем и придумали чтоб быстрее было
... << RSDN@Home 1.1.4 beta 7 rev. 447>>
Valery A. Boronin, RSDN Team, linkedin.com\in\boronin
R&D Mgmt & Security. AppSec & SDL. Data Protection and Systems Programming. FDE, DLP, Incident Management. Windows Filesystems and Drivers.
Здравствуйте, Slava Antonov, Вы писали:
SA>Hello FirstStep, you wrote:
>> Кто знает быстрый способ чтения (последовательного) из файла? Пробовал CreateFile/CreateFileMapping/MapViewOfFile и CreateFile/ReadFile
SA>Тут многое зависит от того, какими порциями вы делаете ReadFile. SA>Размер буфера нужно подбирать экпериментально. У меня в свое время наилучшая скорость достигалась при буфере в 32Кб
SA>-- SA>Всего хорошего, Слава
Спасибо. Насколько понял размер буфера должен быть кратен размеру кластера и размеру страницы памяти. Тогда скорость повышается... Т.е. при буфере в 4096 байт (1 кластер диска и 1 страница памяти) всё идёт быстрее, чем при 2 Мб порции. Просто я думал, что если у HDD аппаратный буфер 2 Мб, то такими порциями и будет оптимальнее читать, оказалось — нет, теперь всё заметно шустрей, да и памяти это использует меньше
FS>>Кроме того на больших файлах постоянный вызов MapViewOfFile/UnmapViewOfFile сильно нагружает систему page fault'ами (видимо постоянное выделение/освобождение памяти) и этот способ оказывается медленнее чем ручное чтение из файла ReadFile'ом. VAB>Зачем Вам постояннй? Конечно тогда нагрузит как надо... Один раз файл спроецируйте и работайте?
У меня такой вопрос: а если файл 7 Гиг, то его ведь за раз не спроецируешь, это даже у Рихтера описывается, что надо создать проекцию с помощью CreateFileMapping, а потом последовательно проецировать с помощью MapViewOfFile небольшую порцию, обрабатывать, освобождать UnmapViewOfFile и так пока весь файл не обработаешь. Попытка отобразить "всё и сразу" грит что недостаточно системных ресурсов. Так что ReadFile и статический буфер (причём небольшого размера (кратного размеру кластера и странице памяти, у мя 4096 байт) даёт куда большее быстродействие и не нагружает систему виртуальной памяти. MMF конечно имеет свои плюсы, но работает медленнее чем "ручное" чтение.
Здравствуйте, FirstStep, Вы писали:
FS>Здравствуйте, Valery A. Boronin, Вы писали:
FS>>>Кроме того на больших файлах постоянный вызов MapViewOfFile/UnmapViewOfFile сильно нагружает систему page fault'ами (видимо постоянное выделение/освобождение памяти) и этот способ оказывается медленнее чем ручное чтение из файла ReadFile'ом. VAB>>Зачем Вам постояннй? Конечно тогда нагрузит как надо... Один раз файл спроецируйте и работайте?
FS>У меня такой вопрос: а если файл 7 Гиг, то его ведь за раз не спроецируешь, это даже у Рихтера описывается, что надо создать проекцию с помощью CreateFileMapping, а потом последовательно проецировать с помощью MapViewOfFile небольшую порцию, обрабатывать, освобождать UnmapViewOfFile и так пока весь файл не обработаешь. Попытка отобразить "всё и сразу" грит что недостаточно системных ресурсов. Так что ReadFile и статический буфер (причём небольшого размера (кратного размеру кластера и странице памяти, у мя 4096 байт) даёт куда большее быстродействие и не нагружает систему виртуальной памяти. MMF конечно имеет свои плюсы, но работает медленнее чем "ручное" чтение.
То, что ReadFile дает куда большее быстродействие у меня есть сомнения. Я в свое время сравнивал скорость чтения с диска — она примерно одинаковая что при использовании MMF, что при чтении с помощью ReadFile (и не удивительно — скорость определяется скоростью чтени с диска; у меня все вертелось в районе 40МБ/c ). Читать по 4К — не самый оптимальный вариант. У меня получалось лучшие результаты при 64K (на некоторых системах наблюдалось уменьшение скорости чтения при увелечении буфера, как ни странно, на некоторых нет ).
Кроме того, статический буфер выравнять по границе страницы — это надо еще пострараться (иначе смысл в кратности?)
Здравствуйте, FirstStep, Вы писали: VAB>>Зачем Вам постояннй? Конечно тогда нагрузит как надо... Один раз файл спроецируйте и работайте?
FS>У меня такой вопрос: а если файл 7 Гиг, то его ведь за раз не спроецируешь, это даже у Рихтера описывается, что надо создать проекцию с помощью CreateFileMapping, а потом последовательно проецировать с помощью MapViewOfFile небольшую порцию, обрабатывать, освобождать UnmapViewOfFile и так пока весь файл не обработаешь. Попытка отобразить "всё и сразу" грит что недостаточно системных ресурсов. Так что ReadFile и статический буфер (причём небольшого размера (кратного размеру кластера и странице памяти, у мя 4096 байт) даёт куда большее быстродействие и не нагружает систему виртуальной памяти. MMF конечно имеет свои плюсы, но работает медленнее чем "ручное" чтение.
конечно если 7 Гб на 32-bit OS то только перепроецированием можно решить вопрос. Либо перейти на 64-bit и проецировать сколько душе угодно. Насчет ReadFile — все равно в итоге с Mm работают FSD, просто вероятно у них лучше Вас получается пока все делать вот и быстродействие выше.
Нельзя вот так вот заявить мол MMF медленнее. Все зависит от условий, задачи и способа решеиня в конкретных условиях.
... << RSDN@Home 1.1.4 beta 7 rev. 447>>
Valery A. Boronin, RSDN Team, linkedin.com\in\boronin
R&D Mgmt & Security. AppSec & SDL. Data Protection and Systems Programming. FDE, DLP, Incident Management. Windows Filesystems and Drivers.
Здравствуйте, Slava Antonov, Вы писали:
SA>Hello FirstStep, you wrote:
SA>Насколько мне известно, даже когда вы делаете ReadFile, система создает MMF.
А происходит ли это при открытии файла с флагом FILE_FLAG_NO_BUFFERING? Будь я разработчиком драйвера файловой системы, я бы все запросы к файлам, открытым с таким флагом пропускал вниз к драйверу диска так, как они есть...
Hello TarasCo, you wrote:
> А происходит ли это при открытии файла с флагом FILE_FLAG_NO_BUFFERING?
Не знаю. Покопался в "Inside W2K".
Возможно это будет интересно:
"Fast I/O
Fast I/O is a special mechanism that allows the I/O system to bypass generating an IRP and instead go directly to the file system driver or cache manager to complete an I/O request. (Fast I/O is described in detail in Chapters 11 and 12.) A driver registers its fast I/O entry points by entering them in a structure pointed to by the PFAST_IO_DISPATCH pointer in its driver object."
"Scatter/Gather I/O
Windows 2000 also supports a special kind of high-performance I/O that is called scatter/gather, available via the Win32 ReadFileScatter and WriteFileGather functions. These functions allow an application to issue a single read or write from more than one buffer in virtual memory to a contiguous area of a file on disk. To use scatter/gather I/O, the file must be opened for noncached I/O, the user buffers being used have to be page-aligned, and the I/Os must be asynchronous (overlapped). Furthermore, if the I/O is directed at a mass storage device, the I/O must be aligned on a device sector boundary and have a length that is a multiple of the sector size."
