тестировал программу чтения/записи файла на файле 531 Мб и процессоре 863 МГц подсчитал что только на чтение файла функцией ReadFile уходит 1 мин 22 сек, только на запись файла функцией WriteFile уходит 1 мин 28 сек, если же читать файл ReadFile, затем вызывать SetFilePointer и только потом WriteFile то на это уходит аж 7 мин 12 сек отсюда вопрос - чем заменить SetFilePointer?
wasmer Если читаешь и пишешь в разные места, то ничем не заменишь. Вызов SetFilePointer с начала или конца файла приводит к чтению информации о физическом размещении файла на диске, что само по себе занимает много времени. Чтение и запись выполняются с текущей позициии, поэтому в принципе могут занимать меньше времени. Попробуй перемещать указатель с текущей позиции (если это возможно), может быть получишь какой-то выигрыш.
wasmer Мэппированием отдельных регионов файла Пролистай в МСДН функции CreateFileA CreateFileMapping MapViewOfFile думаю, при мэппировании отдельных частей файла и записью/чтением в них можно добиться значительного выиграша в скорости
в CreateFileMapping настораживает один момент: If an application specifies a size for the file mapping object that is larger than the size of the actual named file on disk, the file on disk is increased to match the specified size of the file mapping object то есть ее вызывать опасно для файла
вызываю так: Код (Text): invoke CreateFile,addr [esi].cFileName, GENERIC_READ Or GENERIC_WRITE,FILE_SHARE_READ or FILE_SHARE_WRITE,NULL,OPEN_EXISTING,0,NULL попутно заметил ещё такую особенность в Windows 2000 - если копировать 531 мб файл с одного диска на другой на это уходит 3 минуты, если же в другое место на том же диске то аж 10 минут
crypto Чтение данных никак не может занимать меньше времени, чем определение размещения блоков файла, т.к. в процессе его всё равно они определяются. А последнее также не может занимать много времени, т.к. в случае NTFS это несложные математические подсчёты, а в FAT - чтение небольшого участка диска, правда, непоследовательно, если файл сильно фрагментирован. wasmer Сам копируешь или через CopyFile?
если мапить сразу весь файл то можно сразу указать его размер этой функции - проблем нет, но я хочу мапить файл частями допустим по 256 байт, что тогда будет с последней промапленой частью - увеличится ли размер от этого у файла на диске?
wasmer Хм Вероятно ты чего-то не понимаешь Ты мэпируешь ВЕСЬ! файл. Не важно сколько он весит, 5 кб и 2 Тб А вот работаешь непосредственно только с частью карты. Усек? hMap = CreateFileMappingA(hFile, 0, PAGE_READWRITE, 0,0,0) Вот так ты мэпишь файл. Ничто никуда не увеличивается и не уменьшается. Создается карта всего файла. Просто с файловой таблицы считываются данные о файле и его размере. А вот непосредственно чтение с диска - это MapViewOfFile. Смотришь частями. И пишешь тоже частями. Дальше положенного не уедешь ) система не позволит
Great Точно. Вторую функцию у себя исправил. это по невнимательности у меня. MapViewOfFileEx - я думаю ему и обычной MapViewOfFile хватит
это понятно, но MapViewOfFile мапит гранулярно, то есть по 256 байт никак не получится, хорошо если гранулы в системе 64 Кбайт, а если несколько Мбайт - программа ведь столько памяти сожрёт
IceStudent Я имел в виду, что поскольку, видимо, у топикстартера таких операций чтения-записи очень много и результирующие потери времени могут быть уже ощутимыми. Даже если данные о размещении файла на диске постоянно хранятся в памяти, многократное к ним обращение приводит к потерям.
wasmer По поводу памяти. К концу операции воода-вывода в файл юзай UnmapViewOfFile. Так ты освобождаешь память. Усек?
wasmer Эх, все забыли про механику - головки-то надо перемещать, а это - вечность по-сравнению с операциями процессора.
