Некоторые элементы, которые могут встречаться в шаблонах, являются более эффективными, чем ряд других. Например, гораздо эффективней использовать символьный класс [aeiou] вместо набора альтернатив (a|e|i|o|u). Как правило, более простая конструкция является более эффективной. Книга Джеффри Фридла содержит много обсуждений вопроса оптимизации регулярных выражений.
В случае, если шаблон начинается с .* и используется флаг PCRE_DOTALL, шаблон неявно заякоривается, так как он может совпадать только в начале строки. Но если PCRE_DOTALL не используется, PCRE не может выполнить соответствующую оптимизацию, так как в таком случае метасимвол '.' не соответствует символу начала строки (если обрабатываемые данные содержат переводы строк, такой шаблон может соответствовать шаблону не от начала строки, а от позиции непосредственно после перевода строки). Например, применяя шаблон (.*) second к строке "first\nand second" (где \n обозначает символ перевода строки), значение, захваченное первой подмаской, будет 'and'. Чтобы обработать все возможные точки соответствия, PCRE пытается сопоставить шаблон после каждого символа перевода строки.
В случае, если вы используете подобные шаблоны для обработки данных, не содержащих переводы строк, для лучшей производительности используйте модификатор PCRE_DOTALL, либо начинайте шаблон с ^.* для указания явного заякоривания. Это предотвратит PCRE от поиска символов новых строк и дополнительных попыток сопоставить шаблон с каждой такой найденной позицией.
Избегайте шаблонов, которые содержат вложенные неограниченные повторения. Сопоставление их со строками, не содержащими совпадений, занимает длительное время. Рассмотрим пример шаблона (a+)*
Он может соответствовать с "aaaa" 33-мя различными способами, и эта цифра очень быстро растет при увеличении строки. (В данном примере, квантификатор * может совпадать 0, 1, 2, 3 или 4 раза, и для каждого такого случая, кроме нуля, квантификатор + также может совпадать различное число раз.) Если остаток шаблона таков, что все совпадение терпит неудачу, PCRE должна попробовать все возможные варианты совпадения, что может потребовать огромного количества времени.
При помощи оптимизации можно отловить наиболее простые случаи, такие как (a+)*b где следом идёт литеральный символ. Прежде, чем производить стандартную процедуру поиска, PCRE проверяет в последующей подстроке наличие символа 'b', и, в случае отсутствия такового, попытка сопоставления немедленно завершается неудачей. Однако, когда последующего литерала нет, оптимизация не может быть применена. Вы можете ощутить разницу, сравнив поведение (a+)*\d с поведением приведенного выше шаблона. Первый определяет невозможность сопоставления практически сразу же, при сопоставлении со строкой состоящей из символов 'a', в то время как второй тратит длительное время на поиск в строках длиннее 20 символов.