Вы не зашли.
Мне нужно написать процедуру (используя ассемблер + Win32 API), которая бы посчитала контрольные значения для указанного файла тремя способами. Размер файла не ограничивается, поэтому в общем случае можно считать, что его не удастся загрузить в память полностью. Во время своей работы процедура должна показывать объем выполненной работы в дочернем контроле progress bar. В общем, задачка довольно простая, но хотелось бы чтобы эта процедура была оптимизирована по скорости работы, и в то же время имела бы не большой размер кода (но оптимизация по скорости работы более важна). Также хотелось бы, чтобы она в полном объеме использовала ресурсы памяти установленной на компе, т.е. чтобы она при прочих равных работала бы быстрее на той машине, где установлено больше памяти. Процедура ориентирована для работы под Windows9x+ и Windows 2000+. Вот такая задачка. Процедуры для подсчета контрольных значений у меня есть. Осталось только разобраться, как в данном случае лучше всего организовать работу с файлом. Вообще-то я и сам могу это сделать, но у меня ещё мало опыта, поэтому мое решение, скорее всего, не будет оптимальным. Поэтому вопрос к вам: как в данном случае оптимально организовать работу с файлом?
А в чем проблема-то ?
Как я понимаю, для расчета контрольных значений достаточно один раз прочитать файл блоками от начала до конца. Поэтому проблем с памятью вроде как и нет. Зависимости от размера установленной физической памяти реально тоже нет. В данном случае основной тормоз - это ИМХО скорость обмена с диском, особенно если файл фрагментирован.
Так что ИМХО читай себе блоками по 16, 32 или 64 Кб, считай контрольные значения и не парься. Можно открыть файл с флагом FILE_FLAG_NO_BUFFERING - вроде как чуть быстрее получается. Но при этом адрес и размер буфера д.б. кратен 512 байт. Если использовать Buf=VirtualAlloc(Null,..) - автоматом получишь выравнивание на 64Кб.
leo
А в чем проблема-то ?
Да нет, проблемы никакой нет. Просто хотелось бы узнать, как лучше всего это дело организовать. К примеру какой механизм работы с файлами больше подходит в данной ситуации: обычный (ReadFile, WriteFile), обычный с перекрытием (OVERLAPPED) или MMF? Также хотелось бы узнать, как можно подобрать оптимальный размер буфера (или буферов)?
Так что ИМХО читай себе блоками по 16, 32 или 64 Кб, считай контрольные значения и не парься.
А что блоки то такие маленькие, или это не влияет на скорость? IMHO, если использовать механизм работы с файлами с перекрытием и сделать буфера достаточного размера, то можно подсчитывать контрольное значение для одного буфера, в то время как другой за это время будет заполнен следующим блоком файла.
Можно открыть файл с флагом FILE_FLAG_NO_BUFFERING...
Спасибо за подсказку, я обязательно учту её.
Oleg_SK
OVERLAPPED не поддерживается в 9x. Хоть Win98 и маст дай, но еще далеко не дед.
<font color="gray]<font size=2>Windows Me/98/95: For asynchronous read operations, hFile can be a communications resource opened with the FILE_FLAG_OVERLAPPED flag by CreateFile, or a socket handle returned by socket or accept. You cannot perform asynchronous read operations on mailslots, named pipes, or disk files.
Windows Me/98/95: For operations on files, disks, pipes, or mailslots, this parameter must be NULL; a pointer to an OVERLAPPED structure causes the call to fail. (GetLastError = ERROR_INVALID_PARAMETER = 87)</font><!--size--></font><!--color-->
MMF в данном случае работает гораздо дольше. Попробовал для примера два файлика 70 и ~100Мб на разных компах, получилось в ~1.5 и ~2 раза дольше, чем обычное блочное чтение. Эти же примерчики показывают, что увеличение размера буфера свыше 32-64К практически ничего не дает. Кстати, выбор "маленьких" блоков хорош с точки зрения кэширования данных при расчете несколько контрольных значений (хотя повторная загрузка данных из памяти в кэш существенно быстрее чем чтение с диска, но все таки).
Попробуй сам с разными размерами буфера. Для экспериментов кстати нужно обязательно использовать флаг FILE_FLAG_NO_BUFFERING, иначе после первого же прохода файл попадет в файловый кэш и результаты последующих чтений будут занижены.
PS: Что-то народ безмолвствует на эту тему ...
leo
Это именно то, что я хотел услышать! Спасибо за помощь!