PHP PREG_JIT_STACKLIMIT_ERROR – неэффективное регулярное выражение

Что такое PCRE JIT ?

Компиляция «точно в срок» – это супертяжелая оптимизация, которая может значительно ускорить сопоставление шаблонов. Тем не менее, это связано с дополнительной обработкой перед выполнением матча. Таким образом, это очень полезно, если один и тот же шаблон будет сопоставляться много раз.

и как он работает в основном?

PCRE (и JIT) – это рекурсивный, глубинный движок, поэтому ему нужен стек, где локальные данные текущего узла проталкиваются перед проверкой его дочерних узлов … Когда выполняется скомпилированный JIT-код, ему нужен блок памяти для использования в качестве стека. По умолчанию он использует 32K в стеке машины. Однако некоторые крупные или сложные шаблоны нуждаются в большем, чем это. Ошибка PCRE_ERROR_JIT_STACKLIMIT задается, когда недостаточно стека.

По первой цитате вы поймете, что JIT – это дополнительная функция, которая по умолчанию включена в PHP [v7. *] PCRE. Поэтому вы можете легко отключить его: pcre.jit = 0 (это не рекомендуется)

Однако, получая код ошибки # 6 функций preg_* это означает, что JIT достигает предела размера стека.

Поскольку группы захвата потребляют больше памяти, чем группы, не связанные с захватом (еще больше памяти предназначено для использования в соответствии с типом квантификатора кластеров):

1. Группа захвата OP_CBRA ( pcre_jit_compile.c: # 1138 ) – (реальная память больше, чем эта):

 case OP_CBRA: case OP_SCBRA: bracketlen = 1 + LINK_SIZE + IMM2_SIZE; break; 

2. OP_BRA группа OP_BRA ( pcre_jit_compile.c: # 1134 ) – (реальная память больше, чем эта):

 case OP_BRA: bracketlen = 1 + LINK_SIZE; break; 

Поэтому изменение групп захвата в группы, не связанные с захватом, в вашем собственном RegEx заставляет его давать правильный результат (который я точно не знаю, сколько памяти сохранено этим)

Но, похоже, вам нужно захватить группы, и они необходимы. Затем вы должны переписать свой RegEx ради производительности. Backtracking – это почти все в RegEx, которые следует учитывать.

Обновление # 1

Решение :

 (?(DEFINE) (?<recurs> (?! {@|@} ) [^|] [^{@|\\]* ( \\.[^{@|\\]* )* | (?R) ) ) {@ (?<If> \w+)- (?<Condition> (%?\w++ (:\w+)*)* ) (?<True> [|] [^{@|]*+ (?&recurs)* ) (?<False> [|] (?&recurs)* )? \s*@} 

Демо-версия

PHP-код (экранирование обратной косой черты):

 preg_match_all('/(?(DEFINE) (?<recurs> (?! {@|@} ) [^|] [^{@|\\\\]* ( \\\\.[^{@|\\\\]* )* | (?R) ) ) {@ (?<If> \w+ )- (?<Condition> (%?\w++ (:\w+)*)* ) (?<True> [|] [^{@|]*+ (?&recurs)* ) (?<False> [|] (?&recurs)* )? \s*@}/x', $string, $matches); 

Это ваш собственный RegEx, который оптимизирован таким образом, чтобы иметь наименьший шаг назад. Таким образом, все, что должно было быть согласовано с вашим собственным, тоже соответствует этому.

RegEx без следующих вложенных блоков if :

 {@ (?<If> \w+)- (?<Condition> (%?\w++ (:\w+)*)* ) (?<True> [|] [^|\\]* (?: \\.[^|\\]* )* ) (?<False> [|] \X*)? @} 

Демо-версия

Большинство квантификаторов записываются собственнически (избегает обратного хода), добавляя + к ним.

Проблема, которую вы видите, заключается в том, что ваш шаблон неэффективен. Основные причины:

• Вы используете такие подшаблоны: (a+)+b что является лучшим способом для катастрофического возврата
• Вы также используете такие подшаблоны: (a|b)+ который может быть хорошим дизайном, за исключением механизма повторного выражения, такого как pcre
• Вы используете модификатор U по неизвестной причине, из-за чего все ваши кванторы не жадные и генерируют много бесполезных тестов

В стороне есть слишком много бесполезных групп захвата, которые потребляют память ни для чего. Когда вам не нужна группа захвата, не пишите. Если вам действительно нужно группировать элементы, используйте группу, не связанную с захватом, но не используйте группы, не захватывающие захват, чтобы сделать шаблон «более читаемым» (есть другие способы сделать это, например, именованные группы, свободные интервалы и комментарии) ,

Если я хорошо понимаю, вы пытаетесь создать регулярное выражение для preg_replace_callback для обработки инструкции управления вашей системой шаблонов. Поскольку эти управляющие операторы могут быть вложенными, а механизм регулярных выражений не может совпадать с одной и той же подстрокой, вам нужно выбирать между несколькими стратегиями:

1. Вы можете написать рекурсивный шаблон для описания условного оператора, который в конечном итоге содержит другие условные операторы.

2. Вы можете написать шаблон, который соответствует только самым внутренним условным операторам. (Другими словами, он запрещает вложенные условные утверждения.)

В двух случаях вам нужно разбирать строку несколько раз, пока нечего заменить. (Обратите внимание, что вы также можете использовать рекурсивную функцию с первой стратегией, но это усложняет ситуацию.)

Давайте посмотрим на второй способ:

 $pattern = '~ {@ (?<cond> \w+ ) - (?<stat> \w+ (?: % \w+ )* ) (?: : (?<sub> \w+ ) )? \| # a "THEN" part that doesn\'t have nested conditional statements (?<then> [^{|@]*+ (?: { (?!@) [^{|@]* | @ (?!}) [^{|@]* )*+ ) # optional "ELSE" part (the content is similar to the "THEN" part) (?: \| (?<else> \g<then> ) )? (*SKIP) @}~x'; $parsed_view = $string; $count = 0; do { $parsed_view = preg_replace_callback($pattern, function ($m) { // do what you need here. The different captures can be // easily accessed with their names: $m['cond'], $m['stat']... // as defined in the pattern. return $result; }, $parsed_view, -1, $count); } while ($count); 

шаблонная демонстрация

Как вы видите, проблема вложенных операторов решается с помощью цикла do..while и параметра count preg_replace_callback чтобы увидеть, что что-то заменено.

Этот код не проверен, но я уверен, что вы можете его завершить и в конечном итоге адаптировать к вашим потребностям.

В стороне есть много шаблонов, которые уже существуют (и PHP уже является механизмом шаблонов). Вы можете использовать их и избегать создания собственного синтаксиса. Вы также можете посмотреть их коды.