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

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

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

Быстрый способ работы с файлом

Страницы: < 1 2
Piter © (2006-02-03 14:33:00)
Ищется быстрый способ открыть текстовый файл, найти там нужную последовательность символов, скопировать в строку от этой последовательности до другой последовательности.

Файл может занимать несколько десятков мегабайт или даже больше сотни.

Leonid Troyanovsky (2006-02-03 19:37:00) [21]

> Игорь Шевченко © (03.02.06 19:16) [15]

> а с ним спорить мне тем более не хочется. Искать что-либо
> наиболее просто, как мне кажется, в MMF, в данном случае
> для меня критерием является простота.

Насчет простоты, я, кажется уже снабжал Piter'a ссылкой

http://groups.google.com/group/fido7.ru.delphi/msg/64b9f15bdadf6923

Но, видимо, она ему в этой задаче не очень пригодилась.
Кстати, в том обсуждении меня убедили, что CompareMem в [9]
будет нехорошо. Запамятовал, каюсь :)

--
Regards, LVT.

Игорь Шевченко (2006-02-03 19:16:00) [22]
Leonid Troyanovsky © (03.02.06 18:53) [14]

Я охотно верю указанным авторам, но задача задаче рознь, кроме того, Windows сама использует проецирование файлов для своих задач чтения, о чем писал, если не ошибаюсь, Руссинович, а с ним спорить мне тем более не хочется. Искать что-либо наиболее просто, как мне кажется, в MMF, в данном случае для меня критерием является простота.

С уважением,

Leonid Troyanovsky (2006-02-03 18:53:00) [23]

> Игорь Шевченко © (03.02.06 17:51) [10]

> Насколько мне известно, проецирование - наиболее быстрый
> механизм доступа к данным

Во, я нашел про это (в треде есть и ссылка на Slava Usov)

http://groups.google.com/group/fido7.su.win32.prog/msg/b154ddb59929f5cb

Дмитрий, кстати, еще где-то рассказывал про большие тормоза
при чтении из файла размером более оперативки при чтении
из view порциями около 4кб. Т.е., для последовательного чтения
Дмитрий уверен в превосходстве обычного ReadFile, ну а спорить
я с ним не буду.

--
Regards, LVT.

Leonid Troyanovsky (2006-02-03 18:22:00) [24]

> Игорь Шевченко © (03.02.06 18:15) [12]

> Мне словосочетание bred3 ни о чем не говорит, поэтому я
> не могу сказать, что неудача с bred3 означает неудачу попыток

Мне оно тоже ничего не говорит, просто, кажется, что на той
машине нет 2Г памяти.

> проецирования вообще. Тем более, 150 Мб спроецировать вроде
> проблем не составляет :) Я вот только что полтора гигабайта
> спроецировал :)

Проецировать можно, сложности с просмотром на все тело :)

--
Regards, LVT.

Игорь Шевченко (2006-02-03 18:15:00) [25]
Leonid Troyanovsky © (03.02.06 18:01) [11]

Мне словосочетание bred3 ни о чем не говорит, поэтому я не могу сказать, что неудача с bred3 означает неудачу попыток проецирования вообще. Тем более, 150 Мб спроецировать вроде проблем не составляет :) Я вот только что полтора гигабайта спроецировал :)

С уважением,

Leonid Troyanovsky (2006-02-03 18:01:00) [26]

> Игорь Шевченко © (03.02.06 17:51) [10]

> Насколько мне известно, проецирование - наиболее быстрый
> механизм доступа к данным, кроме того, еще и удобный, не
> надо обременяться буферизацией :)

Он, конечно, быстрый (я как-то, вроде здесь, приводил
результаты by Slava Usov), но, целиком его спроецировать
врядли удасться (учитывая неудачу Bred3), а значит о
разрыве на границе все равно придется думать.
А если Piter захочет использовать StrPos, то ему потребуется r/w
для записи последнего #0, значит, будет и не так уж быстро.

--
Regards, LVT.

Игорь Шевченко (2006-02-03 17:51:00) [27]
Leonid Troyanovsky © (03.02.06 17:47) [9]

Насколько мне известно, проецирование - наиболее быстрый механизм доступа к данным, кроме того, еще и удобный, не надо обременяться буферизацией :)

С уважением,

Leonid Troyanovsky (2006-02-03 17:47:00) [28]

> Piter © (03.02.06 15:19) [4]

> я так понимаю спроецировать файл к себе в ВАП.

А зачем проецировать? Ищем одну последовательность,
затем - другую, а промежуток копируем в строку. Т.е.,
двигаемся вперед, сл-но, TFileStream вполне пригоден.
Буфера (пары) в 64К вполне достаточно. Искать прямо в лоб (inc),
сравнивать CompareMem. Оптимизировать что-то здесь сложно,
бо задача решается за один проход.

--
Regards, LVT.

TUser (2006-02-03 17:37:00) [29]
> Piter © (03.02.06 16:17) [6]

КМП могу дать (из дома). Но все равно придется переписать под свою задачу, а для этого придется разобраться в алгоритме. У меня читает файл в поток и ищет там заданную строку.

Игорь Шевченко (2006-02-03 16:40:00) [30]

> мне б готовую реализацию

http://www.google.ru?

Piter (2006-02-03 16:17:00) [31]
TUser © (03.02.06 16:07) [5]

мне б готовую реализацию :)

TUser (2006-02-03 16:07:00) [32]

> Тогда вытекающий вопрос - как оптимально искать в этом файле?

Ищи алгоритм Кнута-Мориса-Пратта или Бойера-Мура. Или один из им аналогичных - см. на алголисте.

Piter (2006-02-03 15:19:00) [33]
Игорь Шевченко © (03.02.06 14:37) [2]
CreateFileMapping + MapViewOfFile

TUser © (03.02.06 15:05) [3]
Тут еще надо поискать оптимальный алгоритм поиска в этом файле

я так понимаю спроецировать файл к себе в ВАП.

Тогда вытекающий вопрос - как оптимально искать в этом файле? Что-то типа PosEx, но работающей не со строками, а с PChar?
Есть у кого такое?

TUser (2006-02-03 15:05:00) [34]
Тут еще надо поискать оптимальный алгоритм поиска в этом файле. Есть много достойных алгоритмов.

Игорь Шевченко (2006-02-03 14:37:00) [35]
CreateFileMapping + MapViewOfFile

Piter (2006-02-03 14:35:00) [36]
проверил с Bred3.

Файл на 34 Mb достаточно быстро открывает, меньше секунды в нем ищет - устраивает.

А вот на 150 Mb открыть не смог - не хватает памяти написал. Думаю, чисто внутренние ограничения. Ну открывал бы 3 секунды.

А мне еще и отображать не надо...

Имеет смысл использовать TextFile? Или думаю лучше сразу с помошью WinApi работать с файлом?

Страницы: < 1 2

Наверх

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