Что-то реализация функции IsVariableMultiLineRegEx на практике перестаёт казаться мне удачной идеей. При написании такой функции с нуля я остановился на группировке () и альтернативах |. Обработка и того, и другого попахивает либо рекурсией, либо вложенными циклами, что, хм, всё усложняет. К тому же я не уверен, что не осталось других синтаксических конструкций, которые тоже надо учесть.
Так что если достоверную информацию о максимальном количестве строк, с которыми совпадёт регулярка, нельзя извлечь после PatCompile, то идею с IsVariableMultiLineRegEx придётся отложить.
Но у меня есть другая гениальная идея.
Почему бы при поиске с регулярками снизу вверх не обрабатывать большие файлы по частям? Грубо говоря, делим файл, к примеру, на 10 частей - и сначала ищем в последней части снизу, затем в предпоследней (в случае мультистрочного поиска захватывая и строки из частей, находящихся ниже, если это необходимо) и т.д.? При этом при каждом переходе на часть, находящуюся выше, мы запоминаем позицию начала предыдущей части, чтобы первая строка текста, совпавшая с регуляркой, никогда не была ниже позиции начала предыдущей, уже обработанной части.
Говоря проще, при переходе от одной части к другой мы как будто смещаем начало документа всё выше. А поскольку мы каждый раз запоминаем позицию начала предыдущей части, то мы не повторяем поиск в уже обработанной ранее части документа.
Важное примечание: это будет работать при отключенной настройке ". совпадает с \n". Если же эта настройка включена, то элементарное ".+" совпадёт со
всем документом, и поэтому должен использоваться поиск от начала документа, как сейчас. А с другой стороны, если в регулярке не встречается ни .+, ни .*, ни \n или \r, то какой смысл в поиске от начала документа? В этом случае лишь пустая трата времени.
Как вариант, можно взять приведенную выше функцию AnalyzeRegExp, и использовать поиск снизу вверх только если она возвращает 1. При этом саму функцию можно упростить, поскольку мы уже не ставим перед собой цель цель подсчитать точное количество строк, с которым может совпасть регулярка, а лишь проверяем её на наличие конструкций, которые делают её неоднострочной.
Это уже вторая гениальная идея за сегодня
