Главная страница
Top.Mail.Ru    Яндекс.Метрика
Текущий архив: 2015.03.01;
Скачать: CL | DM;

Вниз

Быстрое чтение файла   Найти похожие ветки 

 
tri3   (2010-03-26 05:14) [0]

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

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

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


 
MBo ©   (2010-03-26 05:48) [1]

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


 
tri3   (2010-03-26 05:55) [2]

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

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


 
MBo ©   (2010-03-26 07:56) [3]

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


 
Рацелий   (2010-04-09 13:05) [4]

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


 
Дмитрий С ©   (2010-04-11 10:42) [5]

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


 
Anatoly Podgoretsky ©   (2010-04-11 11:31) [6]


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

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


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


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

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

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

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


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


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

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


 
MBo ©   (2010-04-12 18:14) [9]

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


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


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


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

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

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


 
Leonid Troyanovsky ©   (2010-04-12 21:55) [11]


> han_malign   (12.04.10 18:33) [10]

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

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

--
Regards, LVT.


 
Eraser ©   (2010-04-12 23:54) [12]

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


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


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


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

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


 
Anatoly Podgoretsky ©   (2010-04-13 09:20) [14]

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


 
Eraser ©   (2010-04-13 20:06) [15]

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

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

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


 
Игорь Шевченко ©   (2010-04-13 20:59) [16]

Eraser ©   (13.04.10 20:06) [15]

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

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


 
Б   (2010-04-13 21:39) [17]

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


 
[true]TRIx ©   (2010-04-14 19:44) [18]

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



Страницы: 1 вся ветка

Текущий архив: 2015.03.01;
Скачать: CL | DM;

Наверх




Память: 0.51 MB
Время: 0.005 c
6-1274604979
kernel
2010-05-23 12:56
2015.03.01
FD_SETSIZE vs сокеты


2-1391083752
Alex_C
2014-01-30 16:09
2015.03.01
MainMenu не самое врхнее


2-1390933133
Семён
2014-01-28 22:18
2015.03.01
как обработать полученные данные и вывести их в Label


4-1269569649
tri3
2010-03-26 05:14
2015.03.01
Быстрое чтение файла


15-1405110602
Юрий
2014-07-12 00:30
2015.03.01
С днем рождения ! 12 июля 2014 суббота