Столкнулся с проблемой работы с большими файлами и перерыв DRKB и сей форум не смог найти именно то, что меня интересует. Поэтому и создал эту тему.

Есть программа, которая исполняя роль прокси-сервера, попутно индексирует адреса, и их HTTP-залоговки, которые запросил пользователь.
Для индексации программа использует текстовый файл и работает с ним посредством StringList. Сначала записывается адрес, далее - заголовки. Потом второй адрес и его заголовки и т.д. Как вы уже поняли, такой список сортировать нельзя.
Когда пользователь заново запрашивает адрес, который уже "проиндексирован", программа должна определить номер строки необходимого адреса в индекс-файле и выдать следующие строки (это как бы заголовки) до тех пор, когда первые символы следующей выдаваемой строки будут "http://", к примеру.
Поначалу поиск необходимого адреса я делал с помощью функции IndexOf, но когда размер индекс-файла переваливает за 20Мб уже создаются сложности в виду медлительности. Частично "порог" удалось отодвинуть заменив эту функцию на Pos(CRLF+link+CRLF, indx.Text) (CRLF =  #$0D+#$0A;).
Но уже на 30Мб всё уже возвращается на свои места.

Вопрос: существует хоть какой-то вид альтернативы StringList'у? Необходимо записывать данные в конец, но при этом иметь возможность читать файл с начала, чтобы искать необходимые строки (адреса ссылок) и читать строки далее (получать заголовки) (ReadLn???)

Спасибо за понимание.

Может стоит посмотреть в сторону базы данных?

Нет. Условие - работа с текстовыми файлами, простота доступа пользователя к этому файлу.
В конце-концов это как суточный лог-файл - сутки закончатся и будет новый индекс-файл.
Зачем же это всё впихать в одну базу?
Необходимо, чтобы это был именно файл, а не БД.
Помогите.

Есть "легкие" базы данных, например VolgaDB. Высокая скорость работы, вся база в одном файле и т.д. 
Если не устраивает, попробуй FileMapping.

Как насчёт TFileStream?

а списки... TList

Что мешает работать с базой данных, а когда нужен лог - один раз его создавать из базы и давать пользователю (или что там надо?). А саму непосредственную работу проводить с базой.

Ага, я понял, щас объясню.
Обычно файлы индексации весят от 200Мб, поэтому использовать TList, на мой взгляд, не уместно, т.к. файл будет грузиться в оперативную память, а она не резиновая.
TFileStream не позволяет работать с файлом как с набором строк (как это делает TextFile) произвольной длины.
Но TextFile, в свою очередь не может решить вопрос о работе с файлом как для записи строк (в конец) так и чтения всех строк (от 0 - необ. задачи).
THashedStringList такой же тупой как и TStringList - он помещает мой 340Мб файл в ОЗУ, а что другим программам оставить???
К тому же это не лог-файл. Он должен так выглядеть (как лог-файл).
Условие осталось прежним: это должен быть текстовый файл, и ни какая БД.


Это сообщение отредактировал(а) Stern87 - 18.2.2008, 11:17

  Поскольку строки не меняются и не удаляются, то для их хранения можно использовать файл подкачки или просто файл отображаемый в память. Вместо AnsiString юзать PChar. Каждый раз когда нужно будет выделить новый кусок мы просто присваиваем текущий указатель и затем смещаем его на длину строки. Тогда строки будут подгружаться в память по мере обращения, но работа замедлится по сравнению если бы они были в оперативке. Освобождаем удалением файла. Не будет 2х копий. 
  Stern87, в любом случае дешевле купить 2 гига оперативки чем платить тебе зарплату, за то что ты будешь месяц прогу писать  . 

Причём здесь моя зарплата и работа как таковая??
Это - прихоть.
А если индекс-файл может быть больше 2Гб - еще оперативы докупать?
Можно получить такой же "инструмент" как TStringList (в частности: добавление в конец и обращение к конкретной строке) только такой, который бы НЕ загружал этот текстовый файл в ОЗУ? (Это, можно сказать, тот самый вопрос из первого поста)

Это сообщение отредактировал(а) Stern87 - 18.2.2008, 12:27

Можно увидеть обоснование этого? Почему именно так и не иначе? Или дело просто в: 


Это сообщение отредактировал(а) Poseidon - 18.2.2008, 12:32

  Так я ж описал механизм. Скопируй сорс TStringList и переопредели выделение памяти строк инициализацию и т.д. короче все что понадобиться. Но память выделяй сам используя файл отображаемый в память.

Я бы базу в Access хотя бы создал и с ней работал. Вот и альтернатива. 

  Дело в цене, если игра не стоит свеч, то зачем мучаться? Да и как за день может набраться лог на 2 Гига? Поиск в ОЗУ будет самым быстрым. Если грузить с харда, то все намного замедлиться.