Как Total Commander умудряется отображать файл по F3 так быстро. Притом взял файл на 60 Gb по времени 1 сек.

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

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

Читается не весь файл, а отображаемый кусок (с неким запасом).

А как объяснить что моментально прокручивается?

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

Memory Mapped Files - возможное решение, но вовсе не обязательное.
Прочитать мегабайт из нужного места или отобразить этот же мегабайт из MMF - займет ничтожное с точки зрения пользователя время.

tri3, а ты прокрути до конца файла, увидишь что далеко не 60GB он отображает.

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

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

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

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

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

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

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

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

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

>чтобы, например, отобразить скролл?
можно отображать позицию относительно размера

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


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

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

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

> han_malign   (12.04.10 18:33) [10]

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

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

--
Regards, LVT.

в notepad++ грамотно сделано, ничего не тормозит на огромных файлах. это открытый проект - можно посмотреть исходники.

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


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

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

"Быстрые редакторы" нарезают на куски по 64 кб, на ходу строя таблицу, но насколько они быстрые проверяется особыми проверками, например переход на строку 50000.

> [13] DVM ©   (13.04.10 00:40)

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

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

Eraser ©   (13.04.10 20:06) [15]

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

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

Удалено модератором
Примечание: Задай свой вопрос в отдельной ветке

Меня интересуют методы. Хоть пару строк напишите...