Очень хотелось бы работать с большими (порядка 1-2 Гб) файлами как с единым массивом байт, не используя файловые операции ввода-вывода C/C++. Подумал, что для таких целей лучше всего воспользоваться проецированием файлов в память, но когда попытался сие реализовать, наткнулся на ряд подводных камней.

Условия: файлы бинарные, работа с ними предполагает только их чтение, обращение к содержимому преимущественно последовательное, хотя в некоторых случаях будет требоваться и произвольный доступ.

Примерный код в упрощенном виде:


Время от времени программа "спотыкается" при вызове MapViewOfFile. pbFile при этом равен NULL, а функция GetLastError возвращает значение 8 ("Недостаточно памяти для обработки команды"). Причем никак не могу проследить логику возникновения данной ситуации - то файл размером ~1,2 Гб проецируется на ура (при этом запущена куча приложений), то файл ~600 Мб не хочет (притом, что практически ничего не запущено). Утечек памяти в программе нет. Все, что открывается - то закрывается, все что выделяется - то освобождается... Если снять галки с "Build with runtime packages" и "Use dymamic RTL", то ситуация улучшается, можно работать с бОльшими по размеру файлами. Если же ничего к программе не цеплять, то опять нехватка памяти.

От чего зависит размер файла, который можно целиком маппировать в память?
Или придется отказаться от проецирования файла целиком, и маппировать его по кускам? (...чего, собственно, очень хотелось бы избежать, в таком случае уж лучше стандартными C++-средствами с файлом работать...)

А чем тебе не нравиться fstream (fstream - заголовочный файл)? У него же можно указать размер буфера. Или я не правельно понимаю, чего ты хочешь

Это сообщение отредактировал(а) Empirik - 16.2.2006, 13:34

размер файла, который можно спроецировать должен быть меньше размера свободной памяти иначе будет выполняться копирование с диска на диск ( а оно нам надо? )

BreakPointMAN, Вы в одном процессе только один файл отображаете, или несколько?

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


Несколько, по очереди.

То есть у Вас файлы отображаются не одновременно? Сначала один отображаете, с ним работаете, потом все, что с ним связано закрываете/грохаете, опосля беретесь за другой, так? Я спрашиваю, потому что в винде для каждого процесса отводится по 2Гб памяти. Если сумма объемов отображаемых одновременно файлов (в одном процессе) будет превышать это значение, то это может вызвать ту ошибку...

И еще: у Вас последний параметр функции MapViewOfFile (параметр dwNumberOfBytesToMap) равен 0. Вот что про энтот параметр в описании написано:


От указанного смещения до конца секции, а не файла! Черт его знает, что это секция означает, но мож просто туды вместо 0 размер файла влындить для ясности?

Это сообщение отредактировал(а) Lotrex - 16.2.2006, 20:26

Именно так.


Пробовал...



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


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

BreakPointMAN, дядька Рихтер приводил пример обработки больших фалов по частям

Читал, знаю...


но... блин... очень не хотелось бы так делать... одно дело 16 экзабайтов, другое - 1-2 гигабайта... если маппировать по частям, то теряется вся прелесть данного подхода и придется усложнять алгоритм...

Хрен его знает... Я даже не знаю, как можно кучу дефрагментировать.... Может, что бы со всей этой дефрагментацией для работы с файлом отдельный процесс (thread)создавать? У него адресное пространство чистенькое будет, не фрагментированное...

Или отдельную кучу, или thread со своей кучей

ни первое ни второе не реализуемо. на весь процесс адресное пространство одно.

Чтой-то я не понял, к чему это... По моему разумению, у нового процесса (CreateProcess) будет свои 2 Гб виртуальной памяти (нефрагментированной и ничем не занятой). Али я не не прав?

Это сообщение отредактировал(а) Lotrex - 17.2.2006, 18:45

у процесса -- да. но не у потока этого же процесса ( как советовал threef ) и не в этом же процессе ( именно там будет создаваться вторая куча )

Конечно, весь огромный файл отобразить в память не получится.
Да и зачем? Этот какой-то безумный перерасход виртуальной памяти...
Хочешь прозрачно работать с таким файлом как с плоским массивом, напиши простую обертку, которая будет перемещать окно MapView при необходимости. Заодно и открытие\закрытие спрячешь... Размер окна можно подобрать оптимальный, в зависимости от задачи. Мне обычно 64 К хватает.