Мастера DELPHI (документация, исходники, скачать)

Основная («Начинающим»)/ Базы / WinAPI / Компоненты / Сети / Media / Игры / Corba и COM / KOL / FreePascal / .Net / Прочее / RSDN.ORG

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

Быстрое чтение файла [D7, WinXP]

tri3 © (2010-03-26 05:14:00)
Как Total Commander умудряется отображать файл по F3 так быстро. Притом взял файл на 60 Gb по времени 1 сек.

Если бы я его считывал через ReadBlock ушли бы минуты. Или там буфер огромный..

Подскажите, как можно считать файл побайтно максимально быстро. Дельфи.

[true]TRIx (2010-04-14 19:44:00) [1]
Меня интересуют методы. Хоть пару строк напишите...

Б (2010-04-13 21:39:00) [2]
Удалено модератором
Примечание: Задай свой вопрос в отдельной ветке

Игорь Шевченко (2010-04-13 20:59:00) [3]
Eraser © (13.04.10 20:06) [15]

11 мб - мне б такие смешные объемы.

Я стандартным редактором от Far редактирую файлы по сотне мегабайт и ничего не тормозит :) (если строки не очень длинные - не любит редактор Far длинных строк)

Eraser (2010-04-13 20:06:00) [4]
> [13] DVM © (13.04.10 00:40)

ну "огромные" понятие относительное. вот сейчас открыл sql-дамп на 11 МБ (октрылся мгновенно), при первом пролистывании подтормаживало далее пролистывалось мгновенно.

обычный блокнот сначала открывал файл секунд 30 (проц core i5), но потом пролистывал уже без тормозов. в общем, блокнот видимо парсит весь файл целиком.

Anatoly Podgoretsky (2010-04-13 09:20:00) [5]
"Быстрые редакторы" нарезают на куски по 64 кб, на ходу строя таблицу, но насколько они быстрые проверяется особыми проверками, например переход на строку 50000.

DVM (2010-04-13 00:40:00) [6]

> Eraser © (12.04.10 23:54) [12]

> в notepad++ грамотно сделано, ничего не тормозит на огромных
> файлах

А у меня тормозит че-то. И не на таких уж и огромных.

Eraser (2010-04-12 23:54:00) [7]
в notepad++ грамотно сделано, ничего не тормозит на огромных файлах. это открытый проект - можно посмотреть исходники.

Leonid Troyanovsky (2010-04-12 21:55:00) [8]

> han_malign (12.04.10 18:33) [10]

> 2 до 1026 символов(включая CRLF) - погрешность аппроксимации
> ~ 1024/1000000 ~ 0,1% ~ один пиксель на среднем мониторе.

С погрешностью чего-то не так, бо в одном случае 1 000 000 строк,
а в ином - 1 000, но, что-то в этом есть. Допустим, если время
обработки оных разнится на 0.1 сек.

--
Regards, LVT.

han_malign (2010-04-12 18:33:00) [9]

> А как тогда посчитать количество строк в файле, чтобы, например, отобразить скролл?

Нормализованный текст с максимальной длинной строки на несколько порядков меньше размера файла, с небольшой погрешностью аппроксимируется отношением абсолютное смещение/размер...

Например Notepad - устанавливает максимальный размер строки 1024 символа, насильно разбивая строки большего размера. Скажем 1Гб/1024 ==> не менее 1000000 строк с длинной от 2 до 1026 символов(включая CRLF) - погрешность аппроксимации ~ 1024/1000000 ~ 0,1% ~ один пиксель на среднем мониторе...

А просмотровщики с "честными" строками - начинают жутко тормозить уже на паре мегабайт... если не вываливаются на 64К строке...

MBo (2010-04-12 18:14:00) [10]
>чтобы, например, отобразить скролл?
можно отображать позицию относительно размера

Дмитрий С (2010-04-12 16:27:00) [11]

> - разбивка 4Кб строки(буфер нескольких страниц отображения
> "нормального" текста) прямым сканированием делается за <
> 1 мкс...

А как тогда посчитать количество строк в файле, чтобы, например, отобразить скролл?

han_malign (2010-04-12 14:51:00) [12]

> Memory Mapped Files - возможное решение, но вовсе не обязательное.

- я бы даже сказал противопоказанное, т.к. предвыборка вырубается...
Из моего опыта - оптимальный буфер 64К(GetSystemInfo ==> dwAllocationGranularity), CreateFile(..., FILE_FLAG_SEQUENTIAL_SCAN, ...)
З.Ы. FILE_FLAG_SEQUENTIAL_SCAN - увеличивает размер буфера предвыборки, соответственно FILE_FLAG_RANDOM_ACCESS - уменьшает...

> А он переносы строк по CR/LN тоже расставляет за 1 сек?

- разбивка 4Кб строки(буфер нескольких страниц отображения "нормального" текста) прямым сканированием делается за < 1 мкс...

Anatoly Podgoretsky (2010-04-11 11:31:00) [13]

> Рацелий (09.04.10 13:05) [4]

Лучше не прокручивать, а сразу в конец стать.

Дмитрий С (2010-04-11 10:42:00) [14]
А он переносы строк по CR/LN тоже расставляет за 1 сек?

Рацелий (2010-04-09 13:05:00) [15]
tri3, а ты прокрути до конца файла, увидишь что далеко не 60GB он отображает.

MBo (2010-03-26 07:56:00) [16]
Memory Mapped Files - возможное решение, но вовсе не обязательное.
Прочитать мегабайт из нужного места или отобразить этот же мегабайт из MMF - займет ничтожное с точки зрения пользователя время.

tri3 (2010-03-26 05:55:00) [17]
А как объяснить что моментально прокручивается?

Может там как-то Memory Mapped Files задействовано кусками.

MBo (2010-03-26 05:48:00) [18]
Читается не весь файл, а отображаемый кусок (с неким запасом).

Наверх

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