Посоветуйте, какой самый быстрый способ чтения/записи файлов. Имеется файл 4 ГБ (и более). Его надо полностью проанализировать. Я читаю функцией ReadFile по 20 мегов. Не знаю, может быть можно файлы быстрее читать? Если кто знает, подскажите, плиз.

Рома

Полагаю что для больших файлов лучше юзать FileMapping, но не факт что будет быстрее (хотя удобнее определенно) - не проверял :)

Dr.Golova
но не факт что будет быстрее
Через FileMapping будет медленнее (проверял именно на 2Гб и более).

roma
надо полностью проанализировать
Что конкретно надо делать?

Quantum
будет медленнее (проверял именно на 2Гб и более
В чем заключается проверка?
Какие результаты?
На какой конфигурации (hard, soft)?

В чем заключается проверка?
Надо было подсчитать контрольную сумму всего винта (CRC32, вроде) Давно это было... под FAT32 (Windows 95), ~30Гб HD... больше не помню.

Какие результаты?
FileMapping заметно (!) тормозил по сравнению с обычным ReadFile.

Может в NTFS и в новых виндах всё иначе, но, IMHO, если FileMapping тормозил раньше, то от него и сейчас трудно ожидать лучшего.

Quantum
FileMapping заметно (!) тормозил ... Может в NTFS
Я пробовал считать количество строк в большом файле, используя MMF (Very Large File Line Count:). На NTFS медленнее, чем FAT32. Однако в сравнении с thread+ReadFile проигрыша не вижу.

Что конкретно надо делать?
Надо вырезать из dat-файла те участки, где значения выше определенной границы. Т.е., если граница 10, а содержимое файла 01 12 12 32 9, то будет вырезано 12 12 32. Вообще-то это не суть важно, что как надо анализировать файл (анализ гораздо больший), просто мне было интересно, как по самому скоростному читать файл. Я читаю по 20 мегов в буфер, а потом перебираю каждый байт в этом буфере.
Сам анализ занимает достаточно малую часть, 80% времени занимает чтение из файла.
Можно конечно сделать два потока: в одном читать файл, в другом анализировать. А можно еще и третий - для записи на вырезанных участков. Но знаете, прога-то уже готова, а мне переделывать ее совсем не хочется, тем более, что она, можно сказать, пошла в благотворительность.

roma
сделать два потока: в одном читать файл, в другом анализировать
В указанной мною ссылке (в варианте с thread+readfile), отдельные потоки читают и анализируют разные куски файла (наверное, на машине с более чем одним процессором, такой вариант будет быстрее), а не специализируются на определенной работе.
В случае со специализацией потоков я выигрыша не вижу плюс добавляется проблема синхронизации.

FileMapping более удобен потому, что (IMHO) он обращается к ReadFile плюс предоставляет дополнительные возможности.

pas
В моем случае, когда надо обработать весь файл в прямом направлении от начала до конца, вряд ли можно сказать, что FileMapping более удобен. Ладно бы, если бы файл читались куски файла из разных мест в произвольном порядке, другое дело.
Да и тем более меня интересует быстродействие, а не удобства. Че я, японец какой-нибудь, что ли, я же русский (к вопросу о Японских авто).

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

roma
Сделайте вариант с MMF и сравните производительность. (сюда результаты, чтобы была информация для размышления)

пусть файл читается постоянно в отдельном потоке
Куда, в один и тот же буфер?

Т.к. t(чтение) >> t(анализ), то синхронизацию будет не так уж и сложно сделать.
Вы шутите? Не так просто.

одновременно происходит
У Вас сколько процессоров?
Если один, то все происходит псевдоодновременно.
Притом очередной поток может быть прерван в любом месте для передачи кванта времени другому потоку.

Imho писАть многопоточное приложение для вашего случая можно с прицелом на многопроцессорную систему. Afaik чем больше потоков в системе, тем больше между ними конкуренции.

Короче вывод: юзай ReadFile и не НИИ мозги.

Всем спасибо за инфо.

Пока

P2M
Afaik чем больше потоков в системе, тем больше между ними конкуренции
Это особенно заметно на 9x, где многопоточность реализована крайне жидко. IMHO, юзать более двух потоков имеет смысл только на NT.

roma
Короче вывод: юзай ReadFile
Точно