![]() |
| ||
|
|
Новости |
Поиск |
FAQ |
Статьи |
Книги |
Новости VCL
| | Форумы ЧАТ |
Орешник |
|
| |||
| |||
« предыдущая ветвь | форум | следующая ветвь »
Как лучше работать с 300-мегабайтным массивом ? [D7, WinME, WinXP]
Алекс А © (2004-06-21 02:45:00)Есть файл на диске "base1.bin" размером в 300 мегабайт, его надо загрузить в массив Base1 . Делают так :
NewFile := TFileStream.Create('base1.bin', fmOpenRead or fmShareDenyWrite) ;
try
NewFile.ReadBuffer(Base1, 300000000);
finally
NewFile.Free;
end;
Данные используются только для чтения. Загрузка длится более минуты. Хотелось бы, чтобы загрузка шла не сразу от и до, а как то постепенно, по мере обращения программы к отдельным частям массива, чтобы небыло этой минутной паузы. Можно ли это сделать ? Или как вообще лучше это организовать ?
Алекс А (2004-06-24 01:57:00) [1]
> Almaz © (24.06.04 00:43) [64]
Заработало ! :) Грузит моментом. Торможения даже незаметно. Или может просто задачи подходящей не попалось ещё ? Но всё равно очень здорово. Спасибо !
Всем рекомендую.
А с насколько большими файлами можно так работать ? Можно ли с файлами большими High(LongWord) или хотя бы с большими High(Integer) ?
default (2004-06-24 00:58:00) [2]Anatoly Podgoretsky © (23.06.04 11:14) [62]
да, читал я про MMF у Рихтера ничего подобного там не было
Almaz (2004-06-24 00:43:00) [3]
> Алекс А (23.06.04 01:21) [58]
>
> > Almaz © (22.06.04 04:55) [33]
>
> Спасибо за пример! Попробовал так сделать.
> Только у меня не PChar, а Base1 : array[0..SizeB1-1] of
> Longword;
>
> Поменял на Base1 : PLongWord;, так на первом же вызове (
> CountBit(Base1[i1] ) пишет ошибку [Error] Unit1.pas(615):
> Array type required. Что здесь не так ?
Дело в том, что PChar рассматривается Object Pascal как указатель на массив, поэтому запись MyArray[I] - правомерна. А PLongWord - это просто указатель на переменную типа LongWord. Поэтому, для использования массива LongWord его надо описать:
type
TLongwordArray = array [0..MaxInt div 16 - 1] of Longword;
PLongwordArray = ^TLongwordArray;
...
MyArray: PLongwordArray;
...
А в вашем случае:PLongword = ^Longword;- это не массив, поэтому компилятор "ругается".
Удачи.
Palladin (2004-06-24 00:00:00) [4]:)))
Anatoly Podgoretsky (2004-06-23 11:14:00) [5]Роман (23.06.04 09:32) [59]
Здесь правильно только про Рихтера.
Игорь Шевченко (2004-06-23 10:32:00) [6]
> FileMapping ...
> осуществляется посредством прямого копирования данных в
> RAM посредством DMA
Бред
Игорь Шевченко (2004-06-23 10:30:00) [7]
> ответственность за кеширование в первом случае лежит на
> драйверах устройства
Ответственность за кеширование лежит на менеджере кэша, как ни странно
Роман (2004-06-23 09:32:00) [8]FileMapping отличается в корне от ReadFile: ответственность за кеширование в первом случае лежит на драйверах устройства (это может быть не только диск, но и, например, видеокарта AGP!) и осуществляется посредством прямого копирования данных в RAM посредством DMA, во втором же случае - используется буферизированная файловая система Windows. FileMapping всегда быстрее ReadFile т.к. специально разрабатывался для этих целей. Читайте Рихтера, господа.
Алекс А (2004-06-23 01:21:00) [9]
> Almaz © (22.06.04 04:55) [33]
Спасибо за пример! Попробовал так сделать.
Только у меня неPChar, аBase1 : array[0..SizeB1-1] of Longword;
Поменял наBase1 : PLongWord;, так на первом же вызове (CountBit(Base1[i1]) пишет ошибку[Error] Unit1.pas(615): Array type required. Что здесь не так ?
MacroDenS (2004-06-22 14:37:00) [10]
// Что чаще загружается - никогда заранее не известно.
да при первом запуске конечно же неизвестно, а потом после первой загрузки становится известно, особенно если это учитывать.
К примеру можно же создать файл с такой структурой:
ID LoadingNum
1 159
4 87
4567125 14
и так далее...
wicked (2004-06-22 13:18:00) [11]тогда см [39] - писалось для себя...
хотя, если найдутся багофичи, то хотелось бы о них знать... ;)
jack128 (2004-06-22 13:14:00) [12]Да? Нужно попробовать... Хотя я так подумал, меня бы это натолкнуло на такие решения, которые бы замедлили работу с файламии :-)
Все таки подсознательно сидит - раз память, значит быстрый доступ..
wicked (2004-06-22 13:06:00) [13]не совсем...
тут количество переходит в качество - удобство работы предполагает и наталкивает способы, которые никогда бы не пришли в голову, если бы работа с файлом велась через ReadFile...
jack128 (2004-06-22 13:03:00) [14]Итак вывод - MapFile - только для удобства!!! Скорость работы никак не измениться.
wicked (2004-06-22 13:02:00) [15]плюс не стоит забывать, что windows сама кеширует запись в мапленные участки памяти... и при закрытии нужно делать FlushViewOfFile...
wicked (2004-06-22 13:00:00) [16]
> а что, если я эти небольшие участки памяти буду читать с
> помощью ReadFile будет медленнее? Но почему?
не медленнее... геморойней - выделить память, seek, прочесть, опять seek, записать...
а так - отмерил offset скока надо и читай-пиши...
jack128 (2004-06-22 12:56:00) [17]
> именно поэтому произвольный доступ к небольшим участкам
> (до 4 - 16 кб последовательно - 1 - 4 страницы памяти) происходит
> почти мгновенно - коммитятся и наполняются данными необходимые
> страницы...
а что, если я эти небольшие участки памяти буду читать с помощью ReadFile будет медленнее? Но почему?
wicked (2004-06-22 12:46:00) [18]мапирование файла ускоряет доступ к нему не потому, что оно какое то волшебное, а потому, что оно фактически ничего не делает кроме указания менеджеру памяти, что под эти адреса этого процесса "подложен" этот файл...
загрузка данных происходит только тогда, когда аппликация обращается непосредственно к этим адресам... именно поэтому произвольныйдоступ к небольшим участкам (до 4 - 16 кб последовательно - 1 - 4 страницы памяти) происходит почти мгновенно - коммитятся и наполняются данными необходимые страницы...
если же после создания memory mapped файла попытаться последовательно прочесть в цикле все данные, то по скорости этот метод будет равен простому чтению файла с помощью ReadFile...
jack128 (2004-06-22 12:36:00) [19]
> то есть?... если выполнилась ф-ция загрузки, значит он там...
> :)
Под ОЗУ я подрузамеваю модули памяти, а не память виндоуз. Память в Windows физически может распалогаться и на жестком диске и вообще на чем угодно, но эти насители имеют весьма низкую скорость чтения/записи в отличии от ОЗУ. Поэтому я и говорю, что мапирование файла скорость не может увеличить - этот аппаратная проблема. Мапирование лишь отображает файл на ВАП, физически файл никуда не копируется..
wicked (2004-06-22 12:28:00) [20]
> можно узнать, а как ты проверял, что у тя файл в ОЗУ загрузился?
то есть?... если выполнилась ф-ция загрузки, значит он там... :)
> у мя такой вот тестик с 300 метровым файлом 1,5 минуты длился..
очень аппаратно-зависимый тест - на его результаты влияют:
1. скорость дисковой подсистемы...
2. ФС, на которой файл живёт...
3. степень фрагментированности диска...
4. режимы работы харда (дма и т.д.)...
это всё факторы, влияние которых должно быть неощутимо... но это не так... :(