MapViewOfFile: в чем секрет скорости?

[xrob]

И снова здравствуй, любимый форум =)

я добрался до такой темы, как отображение файла в память.
когда-то давно читал, что это очень быстрая вещь и вот наконец решил ее освоить.
Благо в инете пилично информации по этой теме, так что я со всем разобрался и все работает.
но у меня остались вопросы, на которые так и не нашел ответа.

во-первых интересно в чем секрет такой быстроты.

у меня файл 160 метров. это своя простенькая база данных.
прога загружает его целиком в память и там уже разбирает.
раньше загружал с помощью BlockRead по метру, чтобы можно было показывать прогресс загрузки.
для файла 160 метров, точно не помню сколько, но секунд несколько требуется, чтобы полностью загрузить.

Но MapViewOfFile отображет его весь за 0 ms (засекал с GetTickCount);

Конечно, одни функции более оптимальны, чем другие и работают быстрее,
но здесь в обоих случаях нужно проделать минимальный объем работы - скопировать 160 метров в память.
Скопировать - значит взять с харда и положить в оперативную память. Или же нет?

Это наводит на еще один вопрос: при работе с отображением файла, откуда фактически читаются данные?
Они реально лежат в оперативной памяти, или же все-таки читаются с харда?

из всех описаний узнал, что проекция файла доступна для всех процессов и что она как-то связана с файлом подкачки.
насколько я понимаю, файл подкачки - это продолжение оперативной памяти, но уже на харде.

Отсюда возникает такое предположение:
windows что-то там у себя перенастраивает так, что нужный нам файл становится частью файла подкачки.
по крайней мере это очень сочетается с такой быстротой и тем, что файл теперь как бы в оперативной памяти.
Но если это так, то читая такую "память" мы фактически читаем с харда.

Так же написано, что в проекцию файла можно записывать свои данные,
но при этом на хард они сохраняются не сразу, а по запуску функции (что-то с Flush, точно не помню).
С этим в принципе тоже все понятно, кроме одного: как дописать в конец файла, т.е. расширить его.
Этого тоже нигде не нашел.
Есть правда свое предположение - нужно отобразить несуществующую часть файла и писать в нее.
т.е. есть у нас файл 100 байт, а мы отображаем его с 100 байта по 150 и записываем туда.


В общем просьба к тем, кто в этом разбирается - если можно прокомментируйте, пожалуйста, мои рассуждения.

Из всего вышесказанного сформулирую пару вопросов:
1. откуда фактически читаются данные при работе с проекцией?
2. как с помощью проекции дописать в конец файла?

заранее спасибо всем откликнувшимся =)

p.s. я решил, что к winapi это имеет большее отношение, чем к чему-либо еще.

[Аватар]

у меня файл 160 метров. это своя простенькая база данных.
прога загружает его целиком в память и там уже разбирает.
раньше загружал с помощью BlockRead по метру, чтобы можно было показывать прогресс загрузки.
для файла 160 метров, точно не помню сколько, но секунд несколько требуется, чтобы полностью загрузить.

Попробуйте загрузить его по байту, удивитесь на сколько дольше будет. Могу предположить, что маппирование файл в память идет большими блоками и с минимумом накладных расходов, вплоть до оптимизации перемещения головок (но это возможно, не знаю)

[waleri]

Сообщение от xrob

Но MapViewOfFile отображет его весь за 0 ms (засекал с GetTickCount);

MapViewOfFile - это моральный эквивалент CreateFile, который тоже работает быстро. Если хотите сравнивать скорости чтения, пройдитесь по полученному указателю, увидите, что скорости ничем отличаться не будут.

Для добавления данных замапьте новое вью файла после конца файла. По завершении работы лишнее нужно обрезать с помощью SetFileSize(). Кроме того, отметьте, что нельзя отобразить произвольное смещение в файле, смещение должно быть кратным dwPageSize из SYSTEM_INFO структуры. Обычно это 64К.

[min@y™]

Вот, вырвал тебе несколько страниц из умной книжки, покури их.

[Vapaamies]

Сообщение от xrob

windows что-то там у себя перенастраивает так, что нужный нам файл становится частью файла подкачки.

Да, именно так и происходит. Неспроста процедура называется не загрузкой в память, а отображением. Даже больше скажу: ровно с таким же механизмом работает отображение PE-образов -- EXE и DLL, если его не убивают упаковщики типа UPX.

В результате ответственность за нахождение нужных страниц файла в памяти ложится на подсистему виртуальной памяти и подкачки. Размер страницы на x86 -- 4 КБ, вручную может быть включены большие страницы для некоторых процессов -- по 4 МБ. Работа через подсистему подкачки имеет еще то преимущество, что прочитанные страницы могут напрямую передаваться от дисковой подсистемы (кэша) приложению, не тратя дополнительные усилия на копирование в памяти.

[f.hump]

у меня файл 160 метров. это своя простенькая база данных.
прога загружает его целиком в память и там уже разбирает.
раньше загружал с помощью BlockRead по метру, чтобы можно было показывать прогресс загрузки.
для файла 160 метров, точно не помню сколько, но секунд несколько требуется, чтобы полностью загрузить.

Но MapViewOfFile отображет его весь за 0 ms (засекал с GetTickCount);

что-то я сильно сомневаюсь. если вьюв делается (MapViewOfFile(,,0,0,0)) на весь файл сразу, это значит:
выделяется память (160 Мб)
содержимое файла (160 Мб) копируется в выделенную память

и как-то не верится, что такое можно сделать меньше чем за 16-20 мс (ну может одно выделение на 160 Мб пройдет, хотя тут я тоже сомневаюсь).

2. как с помощью проекции дописать в конец файла?

закрыть все вьювы, закрыть мап. создать новый мап больше чем размер файла, открыть вьюв на новом мапе и записать.

Размер страницы на x86 -- 4 КБ, вручную может быть включены большие страницы для некоторых процессов -- по 4 МБ.

почему только для некоторых? если проц поддерживает то для любого можно (кстати не 4 Мб, а 2 Мб).

[waleri]

Сообщение от f.hump

это значит:
выделяется память (160 Мб)
содержимое файла (160 Мб) копируется в выделенную память

Нет, не значит.
Это значит
выделяется память (160МБ)
каждой странице памяти прописывается где в файле она находится
каждая страница памяти помечается как not present
все

До реального обращения к памяти данные из файла не считываются.

Страницы выделяются гранулярностью, указанной в dwPageSize из SYSTEM_INFO структуры. Обычно это 64К для 32бит ОС.

[f.hump]

2waleri
а... хитрожопый манагер мапа, и весь ио управляется где-то там. я должен был догадаться.