| Форумы
ЧАТ |
Орешник |
|
| Форумы -» | Основная («Начинающим»)/ Базы / WinAPI / Компоненты / Сети / Media / Игры / Corba и COM / KOL / FreePascal / .Net / Прочее / RSDN.ORG |
|
| ||
|
|
Новости |
Поиск |
FAQ |
Статьи |
Книги |
Новости VCL
| | Форумы ЧАТ |
Орешник |
|
| |||
| |||
| |||
« предыдущая ветвь | форум | следующая ветвь »
Самый быстрый способ считать маленький файл в строку
Nucer © (2011-10-13 15:59:00)Подскажите самый быстрый способ считать файл в RawByteString. Необходимо обрабатывать около 50 тысяч файлов размеров в 100-200 килобайт.
При таком варианте только на чтение без обработки уходит минут 5:
var
S: RawByteString;
F: File;
Size: Int64;
begin
AssignFile(F, Filename);
Reset(F, 1);
Size := FileSize(F);
Reset(F, Size);
SetLength(S, Size);
BlockRead(F, S[1], 1);
CloseFile(F);
end;
han_malign (2011-10-14 09:15:00) [41]
> Просто вход в папку с 20тыс мелких файлов FAR или проводником (в режиме без иконок) в первый раз занимает около минуты
- добавление 20тыс элементов в TListView(не виртуальный) занимает минут пять(без побочной работы)...
Это надо "чистый" тест делать, и отдельный поток на заполнение списка тоже никто не запрещал(если порядок обработки не имеет значения).
han_malign (2011-10-14 09:06:00) [42]
> открытие и "чтение" 1 файла в 356мб
- не правильный тест:
1. чтения, собственно, не происходит... - надо обратиться к странице памяти, чтобы она подгрузилась(Page Fault)...
2. файл в кэше(даже после закрытия(как минимум метаданные))...
- но направление мысли правильное...
1. сбоев страниц памяти не меньше чем в случае если каждый раз буфер создавать(зависит от менеджера памяти), зато нет дополнительного заполнения нулями(см. VirtualAlloc)...
2. (IMHO) поток не переходит в альтернативное состояние(на ReadFile) и соответственно есть шанс не потерять лишний квант(из тех 2-х, которые 30мс)...
З.Ы. еще можно попробовать FILE_FLAG_SEQUENTIAL_SCAN(без File Mapping), но по этому поводу у меня некоторые сомнения(поможет ли чем-то удвоенный буфер предвыборки если читаешь все?)...
MBo (2011-10-14 08:53:00) [43]Просто вход в папку с 20тыс мелких файлов FAR или проводником (в режиме без иконок) в первый раз занимает около минуты, во второй раз несколько секунд, но тоже не мгновенно.
Slym (2011-10-14 07:24:00) [44]4,3 секунды 50тыс открытие и "чтение" 1 файла в 356мб
procedure TForm1.Button2Click(Sender: TObject);
const FileName='D:\_films\Bones.s03e01.HDTVRip.NovaFilm.TV.avi';//356мб
var
t:dword;
i:integer;
hFile,hMap:THandle;
hMem:pointer;
begin
t:=GetTickCount;
for i:=0 to 50000 do
begin
hFile:=CreateFile(PChar(FileName),GENERIC_READ,FILE_SHARE_READ,nil, OPEN_EXISTING,FILE_ATTRIBUTE_NORMAL, 0);
hMap:=CreateFileMapping(hFile,nil,PAGE_READONLY,0,0,nil);
hMem:=MapViewOfFile(hMap,FILE_MAP_READ,0,0,0);
UnmapViewOfFile(hMem);
CloseHandle(hMap);
CloseHandle(hFile);
end;
t:=GetTickCount-t;
Caption:=InttoStr(t);
end;
Игорь Шевченко (2011-10-13 20:11:00) [45]Смотря зачем читать
Inovet (2011-10-13 18:03:00) [46]> [5] Nucer (13.10.11 16:19)
> На один файл уходит около 30 ms. 50 тысяч файлов - около 25 минут. Ужасно долго.
Зажрались однако.
Inovet (2011-10-13 18:02:00) [47]> [10] Ega23 © (13.10.11 16:30)
> Мол, после какого-то количества (1000, например) сканирование
> начинает ощутимо подтормаживать.
Это на ФАТ, там поиск не индексированный.
RWolf (2011-10-13 17:53:00) [48]вариант: не подгружать файл в буфер вообще.
вместо этого получать отображение файла на память (CreateFileMapping и т. д.).
Dennis I. Komarov (2011-10-13 17:51:00) [49]50000 файлов вдруг оказываются? Может поменять логику и обрабатывать их по мере появления (ReadDirectoryChangesW), или вообще исключить файловый обмен в пользу TCP?
Anatoly Podgoretsky (2011-10-13 16:39:00) [50]> Nucer (13.10.2011 16:19:05) [5]
30 миллисекунд это скорость равна 30-60 мб/сек
Вроде бы это нормально для диска.
sniknik (2011-10-13 16:37:00) [51]> около 50 тысяч файлов размеров в 100-200 килобайт.
а сколько времени занимает например копирование их системой? запись конечно дольше но порядок цифр будет показателен...
один большой файл копируется быстрее чем много много мелких. даже при том что размер большого в много раз больше суммы мелких.
Ega23 (2011-10-13 16:35:00) [52]Ещё один вариант: не делать 50.000 маленьких файлов, а сделать один большой из 50.000 частей.
Омлет (2011-10-13 16:33:00) [53]Сильно ли разбросаны файлы по диску?
Nucer (2011-10-13 16:32:00) [54]> Какая файловая система? Какой носитель?
NTFS, HDD (SATA 5400)
> Ega23 © (13.10.11 16:30) [10]
Попробую раскидать по папкам, вдруг поможет.
Ega23 (2011-10-13 16:30:00) [55]Потом что-то ещё такое было про количество файлов в директории. Мол, после какого-то количества (1000, например) сканирование начинает ощутимо подтормаживать.
Впрочем, с этим к Розычу.
Омлет (2011-10-13 16:30:00) [56]Какая файловая система? Какой носитель?
Nucer (2011-10-13 16:28:00) [57]> А если отключить антивирус?
Отключил первым делом :)
Ega23 (2011-10-13 16:27:00) [58]
> 50 тысяч файлов - около 25 минут.
А щито вы хотели? Дисковая операция.
> Программно никак не ускорить процесс?
Ну если более одного ядра, то можно попробовать распараллелить потоки.
stas (2011-10-13 16:25:00) [59]Nucer (13.10.11 16:19) [5]
А если отключить антивирус?
Nucer (2011-10-13 16:19:00) [60]Выделение памяти на фоне чтения файла выполняется мгновенно. Если убрать строку и читать из файла только один байт, то времени на чтение всех файлов уходит примерно столько же (по байту с каждого).
С TFileStream быстрее не стало. На один файл уходит около 30 ms. 50 тысяч файлов - около 25 минут. Ужасно долго. Программно никак не ускорить процесс?
| |
Страницы: 