Top.Mail.Ru
Мастера DELPHI, Delphi programming community Титульная страница Поиск, карта сайта Написать письмо 
| Новости | Поиск | FAQ | Статьи | Книги | Новости VCL |
| Форумы ЧАТ | Орешник | KOL и MCK |
Форумы -» Основная («Начинающим»)/ Базы / WinAPI / Компоненты / Сети / Media / Игры / Corba и COM / KOL / FreePascal / .Net / Прочее / RSDN.ORG

« предыдущая ветвь | форум | следующая ветвь »

Как лучше работать с 300-мегабайтным массивом ? [D7, WinME, WinXP]


Страницы:   1 2 3 4

Алекс А ©   (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. режимы работы харда (дма и т.д.)...
это всё факторы, влияние которых должно быть неощутимо... но это не так... :(


Страницы:   1 2 3 4

Наверх

Титульная страница Поиск, карта сайта Написать письмо