парсеря понимаю задачу так
1 есть несколько файлов логов
2 есть несколько человек о которых надо извлечь информацию из всех логов
если это так то



ОДИН ЧЕЛОВЕК ЗА ОДИН РАЗ. ПО ГРУППЕ ЛИЦ ИНФОРМАЦИЮ НЕ ИЩЕМ. И фрагмент содержащий UserInfo действительно меньше размера файла. Как правило МНОГО меньше соотношение примерно как десятки МБ (файл) к десяткам Кб(ФРАГМЕНТ).

А вообще я вот в какой пограничной ситуации встрял в тупик. Обработать ситуацию когда сам фрагмент лога попадает на границу текста считанного в буфер. Причем если он попадает на границу вконце Фрагмента ФАЙЛА в буфере поймать можно и не сложно, то вот когда НАЧАЛО фрагмента лога в обном фрагменте буфера (ФРАГМЕНТ А) а все остальное во втором фрагменте (ФРАГМЕНТ Б) вызвало небольшие затруднения
Фрагмент А Фрагмент Б
Толи я уже под вечер плохо соображаю.

Новый вариант парсера сейчас посмотрю. Особенно мне интеренсно то что вы широко API используете. Есть где поучится и кое что в копилку знаний положить.

White OwlНикаких "если". Редкость Иванова никак не влияет на задачу. Упрощай:
Что изначально нужно? Нужно разбить весь лог на куски. Начало одного куска и начало следующего обозначен строкой в которой есть подстрока ">IncomingTime". Если в куске есть подстрока "Иванов", то этот кусок надо запомнить, иначе проигнорировать.

Итого один цикл и в нем два instr или три если текст "Иванов" может появится не только в UserInfo:


Все, и не надо заниматься многочисленным сканированием во всех направлениях.
Принцип KISS никто не отменял.

Выглядит на удивление просто. Завтра с утра опробую непременно.

А что за принцип KISS???

парсералгоритм такой
размер записи Х размер буфера 2Х тогда
если в результате сканирования мы нашли UserInfo во второй половине буфера те позиция >Х and <2х тогда
заведомо начало записи лежит в буфере и мы его находим
если нашли и конец записи в буфере продолжаем как обычно
если не нашли конец записи в буфере то сдвигаем все данные в буфере так чтобы начало записи лежало в позиции 0 ноль и подгружаем новый кусок и ищем конец записи а он заведемо должен быть тк запись загружена с позиции 0

Размер искомого фрагмента лога от IncomingTime до OutgoingTime не фиксирован. Он может быть разным. Поэтому возможен вариант когда прочитали первый фрагмент файла от 0 до 2x и не нашли там UserInfo. Прочитали второй фрагмент нашли там UserInfoа вот IncomingTime от этого UserInfo остался в первой части. Тогда нужно либо переменную strFound постоянно держать в памяти (если действовать как White Owl накоплением) либо я так думаю делать так держать размер буфера побольше, чтобу там умещаляся десяток фрагментов. Тогда при первом сканировании если мы не нашли UserInfo откатываться к ближайшему OutgoingTime. В этом случае следующий фрагмент файла будет начинаться целым, еще не отсканированным фрагментом лога от IncomingTime до OutgoingTime.
парсер1 файлов логов один или несколько в которых храниться информация о конкретном человеке?
2 получается что есть кнопка на форме в которой выбираем человека и для этого человека извлекаем инфу но тогда если в следующий раз мы введем другого человека то опять будем все сканировать
3 так вот если в одном файле хранится информация о всех возможных человеках и список этих возможных человеков известен заранее то можно за один проход извлечь всю информацию сохранить и просто показывать при следующем запросе. конечно если логи меняются со временем и нужны самые свежие данные то это не пройдет

1)Файлов логов много. Каждый день формируется свой файл лога, а информацию меньше чем за полгода не запрашивают. Итого за раз обрабатывается 180 файлов и больше, до 5 лет значится 1800-1900 файлов. Поэтому меня быстродействие та и волнует. Сейчас проверю насчет скорости обработки при росте файла (то что написал White Owl ) если действительно на больших файлах скорости окажутся сопоставимы сделаю обработку до 100 Мб через буфер остальное чтением. Но тут дело такое секундомер нужен :)
2 и 3 ) В файле за один день информации по Иванову может и не быть. Например он в отпуске с 5 по 15 был. я этого не знаю зато там есть Сидоров, Петров и Дятлов, так что размер файла все равно большой. Количество таких Ивановый порядка 1000 в системе и это как говорится не предел. Так что парсить ежедневно и раскладывать информацию отдельно по каждому дело абсолютно лишнее, да и место это опять же скушает даже будучи хорошенько заархивировано. плюс каждый день новый лог добавляется, так что по запросу все равно надо делать дополнительную обработку, а нет ли там Иванова.

В общем бюджет сделан секндомер на столе пошел разбирать логи. Кстати я так по опытам понял что чем больше фрагмент в буфере тем:
1) выше скорость сканирования
2) Меньше возможностей возникновения пограничных ситуаций и проще их обходить.

парсер,

Критерий очень простой формат имени файла ddmmyyyy.log.

У меня кстати на машине P4 2.6 1Гб. Буфер больше 80 метров не уживается пишет OUT OF MEMORY.
Далее при поточной обработке файлов через несколько итераций получаю BED FILE NAME OR NUMBER при записи в файл результата
. я уже и явно номера задал не пойму что делать, не будешь же каждый раз открывать файл перед записью и закрывать после записи. может я что не так делаю.

Alex_men,

Обошел ошибку открывая файл для записи через FSO. Итого по первым тестам 200Мб файл разбор 6 сек. набор файлов в 1ГБ минута. Файлы от 400 кб до 185 мб.

Игорь Горбонос,

Мне тоже интересно. уменьшени с 8 минут до6 секунд это быстро по моим ощущениям. Это отчет в течении часа на любой машине в офисе,а не полутора двух суток на очень хорошей рабочей станции.

Пойду теперь смотреть , то что ребята предлагали.

самое геморойное это выверять результаты :(

ZVI,

я конечно не много еще знаю но по моему ваш совет
а) по временным затратам сопоставим :) Возможно зная смещения информацию из файла можно отобрать быстрее. Но тут еще добавит свою капельку и работа запросов помимо того что все равно надо читать файл и осуществлять позиционирование по нему. А в случае больших файлов и чтение по частям. Не вижу преимуществ, разве что использование проекции в память что то даст. По моему тут как раз тот самый KISS о котором говорилось выше.
б) требует постоянной обработки новых файлов чтобы держать базу со смещениями в актуальном состоянии. Или же перед составлением отчета надо пройтись по всем файлам которые не были обработаны со времени предидущего отчета. Дополнить табличку смещений и потом делать отчет.

Проекция в память у меня стоит в завтрашнем плане изучения. Это интересная тема. Упоминания я находил в темах но конкретных примеров не было, а за источник информации отдельное СПАСИБО.

парсер,

Черт подери эту поддержку вместе с разработчиками. Вы были правы у них таки есть ситуации при которых идет переплетенние двух блоков информации по двум разным клиентам. Причем программа разбора логов разработчиков эти фрагменты вообще игнорит.

Есть возможность еще отбирать фрагмет по sessionID но это усложнит все по самое немогу. Прийдется видимо ускорить изучение вопроса проекции файлов