Чтение огромных файлов

@slowCheetah · Регистрация: 18.07.2009

Студворк — интернет-сервис помощи студентам

Необходимо выполнять работу с огромными файлами(например в несколько Гб), чтобы после чтения обработать и вывести все в клиенсткую область(mfc приложение), естественно заливать все в память не нужно, да и не получиться... подскажите, пожалуйста, по какому принципу выполнять чтение, может есть статьи какие, ссылки, что можете посоветовать почитать. сначала хотел все организовать так: читаю какой-то кусок, обрабатываю и т.п., заполняю, а при скроллинге дочитываю еще, при том чтобы общий объем выведенного не превышал по размеру считаное с самого начала, вот... но потом запустил одно установленное у меня приложение(на тот момент в памяти приложение занимало около 5мб), загрузил в него файл размером порядка 100мб, при этом занимаемый приложением объем в памяти учеличился где-то на 1-2мб, после этого удалил загруженный файл(с жесткого диска) и приложение нормально работало, как будто файл был загружен в память. вот может кто знает где что по этому поводу почитать можно, может кто подскажет) а windjview, кстати, все в память заливает

@XuTPbIu_MuHTAu · 18.07.2009, 21:34

Ключевая фраза - Memory mapped files. тут можно посмотреть msdn, или почитать еще что-нибудь где-нибудь.

@slowCheetah · 18.07.2009, 21:40 **[ТС]**

Спасибо большое! Рихтера обязательно почитаю, а если мне WinApi не подходит по причине переносимости, тогда как быть ?

@XuTPbIu_MuHTAu · 18.07.2009, 21:52

Ну если MFC приложение - о переносимости большей чем у WinAPI не может быть и речи.. общего способа я не знаю,но может он и есть. В крайнем случае можно повыпендриваться с дефайнами, написав варианты под виндоус и линукс.

@odip · 20.07.2009, 09:03

Если у тебя MFC-приложение, то о какой переносимости в Linux/BSD/Unix может вообще идти речь ?

Что касается memory mapped files - то все это есть под Unix, код писать проще чем в Windows.

Чтобы тебе что-то посоветовать желательно указать в общих чертах что вообще делает твое приложение с огромными файлами ?

@slowCheetah · 20.07.2009, 12:26 **[ТС]**

Переносиомсть я указал не имея ввиду мое конкретное приложение, уважаемый товарищ, odip... меня просто интересовал способ организации альтернативы этого самого memory mapped files не касаясь WinApi...

@IT_Exp · 20.07.2009, 12:40

меня просто интересовал способ организации альтернативы этого самого memory mapped files не касаясь WinApi...
_fseeki64

@odip · 20.07.2009, 14:14

меня просто интересовал способ организации альтернативы этого самого memory mapped files не касаясь WinApi...

Под UNIX есть memory mapped files - смотреть в сторону функций mmap(), munmap().

fseek() - это не совсем то, но для эмуляции mmap годится.

@IT_Exp · 20.07.2009, 14:35

odip,
fseek() - это не совсем то

читай первое сообщение. аффтару нужно
выполнять работу с огромными файлами(например в несколько Гб)

@odip · 20.07.2009, 15:15

читай первое сообщение. аффтару нужно
выполнять работу с огромными файлами(например в несколько Гб)

Я так понял он спрашивает как сделать memory mapped на Unix.

Кстати тогда лучше использовать fseeko() - это более портабельно, чем _fseeki64().

@IT_Exp · 20.07.2009, 15:17

про unix и mmf - это ты мОщно телепатнул, преклоняюсь

@resource · 22.07.2009, 13:32

Ну что касается мапинга то его размер ограничивается адресным пространством процесса. Т.е. 2 Гб (32битное пользовательское пространство) минус 64 кб нижних адресов минус пространство уже занятое какими-то данными (а без этого не бывает).
Вопрос чтения больших файлов актуален и по сей день. Мне самому интересно как читать файл в несколько ГБ. Особенно если пишешь свой редактор аля блокнот. Читать (мапить) можно конечно кусками. Но как без лагов скролить файл размеров в несколько гигов, особенно если используется стандартный эдит (ричэдит)?

@IT_Exp · 22.07.2009, 13:45

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

@odip · 22.07.2009, 13:55

Я думаю стандартные компоненты не годятcя.
Текстовый редактор UltraEdit работает с файлами в несколько Gb.

@resource · 22.07.2009, 14:02

Короче говоря надо пробовать, тут задали неплохую тему для упражнений.

@Patch · 22.07.2009, 14:03

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

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

да где проблема-то?
ремэппинг куска файла занимает несколько миллисекунд.
делал я такой... давно...
тогда тоже интересно было.

@resource · 22.07.2009, 14:15

Есть ещё один интересный, в этом плане, товарищ - старина хью версии 6.11 и иже с ним. 16-битная софтина досовского посола не знала не про какие мапинги, а тормозов при скролинге вообще не ведает.
Справедливости ради надо сказать что там и скролбара конечно никакого нет, но подгружать без мапинга куски файла (не лагая) это уже круто

Новые блоги и статьи Все статьи Все блоги /
SDL3 для Desktop (MinGW): Рисуем цветные прямоугольники с помощью рисовальщика SDL3 на Си и C++ 8Observer8 17.03.2026 Содержание блога Финальные проекты на Си и на C++: finish-rectangles-sdl3-c. zip finish-rectangles-sdl3-cpp. zip	Символические и жёсткие ссылки в Linux. algri14 15.03.2026 Существует два типа ссылок — символические и жёсткие. Ссылка в Linux — это запись в каталоге, которая может указывать либо на inode «файла-ИСТОЧНИКА», тогда это будет «жёсткая ссылка» (hard link),. . .	[Owen Logic] Поддержание уровня воды в резервуаре количеством включённых насосов: моделирование и выбор регулятора ФедосеевПавел 14.03.2026 Поддержание уровня воды в резервуаре количеством включённых насосов: моделирование и выбор регулятора ВВЕДЕНИЕ Выполняя задание на управление насосной группой заполнения резервуара,. . .	делаю науч статью по влиянию грибов на сукцессию anaschu 13.03.2026 прикрепляю статью
SDL3 для Desktop (MinGW): Создаём пустое окно с нуля для 2D-графики на SDL3, Си и C++ 8Observer8 10.03.2026 Содержание блога Финальные проекты на Си и на C++: hello-sdl3-c. zip hello-sdl3-cpp. zip Результат:	Установка CMake и MinGW 13.1 для сборки С и C++ приложений из консоли и из Qt Creator в EXE 8Observer8 10.03.2026 Содержание блога MinGW - это коллекция инструментов для сборки приложений в EXE. CMake - это система сборки приложений. Здесь описаны базовые шаги для старта программирования с помощью CMake и. . .	Как дизайн сайта влияет на конверсию: 7 решений, которые реально повышают заявки Neotwalker 08.03.2026 Многие до сих пор воспринимают дизайн сайта как “красивую оболочку”. На практике всё иначе: дизайн напрямую влияет на то, оставит человек заявку или уйдёт через несколько секунд. Даже если у вас. . .	Модульная разработка через nuget packages DevAlt 07.03.2026 Сложившийся в . Net-среде способ разработки чаще всего предполагает монорепозиторий в котором находятся все исходники. При создании нового решения, мы просто добавляем нужные проекты и имеем. . .

@slowCheetah 11 / 11 / 2 Регистрация: 18.07.2009 Сообщений: 123

	Чтение огромных файлов 18.07.2009, 21:12. Показов 2680. Ответов 16 Метки нет (Все метки) Необходимо выполнять работу с огромными файлами(например в несколько Гб), чтобы после чтения обработать и вывести все в клиенсткую область(mfc приложение), естественно заливать все в память не нужно, да и не получиться... подскажите, пожалуйста, по какому принципу выполнять чтение, может есть статьи какие, ссылки, что можете посоветовать почитать. сначала хотел все организовать так: читаю какой-то кусок, обрабатываю и т.п., заполняю, а при скроллинге дочитываю еще, при том чтобы общий объем выведенного не превышал по размеру считаное с самого начала, вот... но потом запустил одно установленное у меня приложение(на тот момент в памяти приложение занимало около 5мб), загрузил в него файл размером порядка 100мб, при этом занимаемый приложением объем в памяти учеличился где-то на 1-2мб, после этого удалил загруженный файл(с жесткого диска) и приложение нормально работало, как будто файл был загружен в память. вот может кто знает где что по этому поводу почитать можно, может кто подскажет) а windjview, кстати, все в память заливает 0

@XuTPbIu_MuHTAu 2256 / 771 / 25 Регистрация: 27.05.2008 Сообщений: 1,496
	18.07.2009, 21:34
	Ключевая фраза - Memory mapped files. тут можно посмотреть msdn, или почитать еще что-нибудь где-нибудь. 1

@slowCheetah 11 / 11 / 2 Регистрация: 18.07.2009 Сообщений: 123
	18.07.2009, 21:40 [ТС]
	Спасибо большое! Рихтера обязательно почитаю, а если мне WinApi не подходит по причине переносимости, тогда как быть ? 0

@XuTPbIu_MuHTAu 2256 / 771 / 25 Регистрация: 27.05.2008 Сообщений: 1,496
	18.07.2009, 21:52
	Ну если MFC приложение - о переносимости большей чем у WinAPI не может быть и речи.. общего способа я не знаю,но может он и есть. В крайнем случае можно повыпендриваться с дефайнами, написав варианты под виндоус и линукс. 0

@odip 7176 / 3234 / 82 Регистрация: 17.06.2009 Сообщений: 14,164
	20.07.2009, 09:03
	Если у тебя MFC-приложение, то о какой переносимости в Linux/BSD/Unix может вообще идти речь ? Что касается memory mapped files - то все это есть под Unix, код писать проще чем в Windows. Чтобы тебе что-то посоветовать желательно указать в общих чертах что вообще делает твое приложение с огромными файлами ? 0

@slowCheetah 11 / 11 / 2 Регистрация: 18.07.2009 Сообщений: 123
	20.07.2009, 12:26 [ТС]
	Переносиомсть я указал не имея ввиду мое конкретное приложение, уважаемый товарищ, odip... меня просто интересовал способ организации альтернативы этого самого memory mapped files не касаясь WinApi... 0

@IT_Exp MCSD: APP BUILDER 8795 / 1074 / 104 Регистрация: 17.06.2006 Сообщений: 32,602
	20.07.2009, 12:40
	меня просто интересовал способ организации альтернативы этого самого memory mapped files не касаясь WinApi... _fseeki64 0

@IT_Exp MCSD: APP BUILDER 8795 / 1074 / 104 Регистрация: 17.06.2006 Сообщений: 32,602
	20.07.2009, 14:35
	odip, fseek() - это не совсем то читай первое сообщение. аффтару нужно выполнять работу с огромными файлами(например в несколько Гб) 0

@IT_Exp MCSD: APP BUILDER 8795 / 1074 / 104 Регистрация: 17.06.2006 Сообщений: 32,602
	20.07.2009, 15:17
	про unix и mmf - это ты мОщно телепатнул, преклоняюсь 0

@resource 7 / 7 / 1 Регистрация: 22.07.2009 Сообщений: 104
	22.07.2009, 13:32
	Ну что касается мапинга то его размер ограничивается адресным пространством процесса. Т.е. 2 Гб (32битное пользовательское пространство) минус 64 кб нижних адресов минус пространство уже занятое какими-то данными (а без этого не бывает). Вопрос чтения больших файлов актуален и по сей день. Мне самому интересно как читать файл в несколько ГБ. Особенно если пишешь свой редактор аля блокнот. Читать (мапить) можно конечно кусками. Но как без лагов скролить файл размеров в несколько гигов, особенно если используется стандартный эдит (ричэдит)? 0

@IT_Exp MCSD: APP BUILDER 8795 / 1074 / 104 Регистрация: 17.06.2006 Сообщений: 32,602
	22.07.2009, 13:45
	Но как без лагов скролить файл размеров в несколько гигов, особенно если используется стандартный эдит (ричэдит)? Думаю что в таком случае нужно переопределять логику работы контрола (сабклассинг) чтобы подпихивать ему данные по необходимости. 0

@odip 7176 / 3234 / 82 Регистрация: 17.06.2009 Сообщений: 14,164
	22.07.2009, 13:55
	Я думаю стандартные компоненты не годятcя. Текстовый редактор UltraEdit работает с файлами в несколько Gb. 0

@resource 7 / 7 / 1 Регистрация: 22.07.2009 Сообщений: 104
	22.07.2009, 14:02
	Короче говоря надо пробовать, тут задали неплохую тему для упражнений. 0

@resource 7 / 7 / 1 Регистрация: 22.07.2009 Сообщений: 104
	22.07.2009, 14:15
	Есть ещё один интересный, в этом плане, товарищ - старина хью версии 6.11 и иже с ним. 16-битная софтина досовского посола не знала не про какие мапинги, а тормозов при скролинге вообще не ведает. Справедливости ради надо сказать что там и скролбара конечно никакого нет, но подгружать без мапинга куски файла (не лагая) это уже круто 0