Существует много дискуссий о том, что быстрее и лучше.
Если вы планируете когда-нибудь перейти на PHP6, ваше решение будет принято. В противном случае:
По общему мнению, PCRE - лучшее универсальное решение, но если у вас есть конкретная страница с большим трафиком и вам не нужен PHP6, возможно, стоит провести некоторое тестирование.
Например, из комментариев к руководству по PHP:
Устаревшее регулярное выражение POSIX в PHP для
Поиск Perl похож на замену
деревянные доски и кирпич для дома
с готовыми комнатами и стенами.
Конечно, вы можете смешивать и сочетать
некоторые части, но это много
легче изменить со всеми частями
выложены перед вами.
PCRE быстрее, чем POSIX RE? Не всегда.
В недавнем поисковом проекте здесь
в Cynergi у меня была простая петля с
несколько симпатичных функций ereg_replace (), которые
Потребовалось 3 минуты для обработки данных. Я изменился
этот 10-строчный цикл в 100-строчный
рукописный код для замены и
цикл теперь занял 10 секунд, чтобы обработать
те же данные! Это открыло мне глаза на то, что
может В НЕКОТОРЫХ СЛУЧАЯХ быть очень медленным
регулярные выражения. В последнее время я решила
заглянуть в Perl-совместимый регулярный
выражения (PCRE). Большинство страниц утверждают
PCRE быстрее, чем POSIX, но несколько
утверждай иначе. Я решила на
бешмарки мои. Мои первые несколько
тесты подтвердили, что PCRE будет быстрее,
но ... результаты были немного
отличается от других, так
Я решил сравнить каждый случай
Использование RE, которое я имел на 8000-линейном безопасном
(и быстро) проект веб-почты здесь
Cynergi, чтобы проверить это. Результаты, достижения?
Неопределенный! Иногда PCRE являются
быстрее (иногда в разы
чем в 100 раз быстрее!), но некоторые другие
времена POSIX RE быстрее (в
2x). Я все еще должен найти правило на
когда один или другой быстрее. Это
не только о размере поисковых данных,
количество данных соответствует, или "RE
время компиляции ", которое показало бы
когда вы часто повторяли функцию:
всегда будет быстрее, чем
Другой. Но я не нашел образец
Вот. Но, по правде говоря, я тоже не сделал
найдите время, чтобы посмотреть в источник
код и проанализировать проблему. Я могу
приведу несколько примеров.
POSIX RE
([0-9] {4}) / ([0-9] {2}) / ([0-9] {2}) [^ 0-9] +
([0-9] {2}): ([0-9] {2}): ([0-9] {2})
На 30% быстрее в POSIX, чем когда
преобразован в PCRE (даже если вы используете \ d
и \ D и не жадное сопоставление). На
С другой стороны, аналогично PCRE
сложный шаблон / [0-9] {1,2} [
\ t] + [a-zA-Z] {3} [\ t] + [0-9] {4} [
\ Т] + [0-9] {1,2}: [0-9] {1,2} (: [0-9] {1,2})? [
\ t] + [+ -] [0-9] {4} / в 2,5 раза быстрее
PCRE, чем в POSIX RE. просто
шаблоны замены, такие как
ereg_replace ("[^ a-zA-Z0-9 -] +", "", $ m
); в 2 раза быстрее в POSIX RE, чем
PCRE. И тогда мы снова запутались
потому что шаблон POSIX RE, как
(^ | \ n | \ r) begin-base64 [\ t] + [0-7] {3,4} [
\ t] + ...... в 2 раза быстрее POSIX RE,
но нечувствительный к регистру PCRE
/ ^ Получено [\ t] *: [\ t] от [\ t] + ([^
\ t] +) [\ t] / i в 30 раз быстрее, чем его
POSIX RE версия! Когда дело доходит до
чувствительность к регистру, PCRE пока
казалось лучшим вариантом. Но я
нашел действительно странное поведение
от Эрега / Eregi. На очень простом
POSIX RE (^ | \ r | \ n) mime-версия [\ t] :
Я обнаружил, что eregi () принимает 3,60 с (просто
номер в тесте), в то время как
Соответствующий PCRE занял 0,16 с! Но если
Я использовал ereg () (с учетом регистра)
Время POSIX RE сократилось до 0,08 с! Так что я
исследовано дальше. Я пытался сделать
сам POSIX RE не зависит от регистра.
Я дошел до этого:
(^ | \ Г | \ п) [мМ] [Ii] [мМ] [еЕ] -vers [Ii] [Oo] [NN] [
\ t] *: эта версия также заняла 0,08 с.
Но если я попытаюсь применить то же правило к
любой из 'v', 'e', 'r' или 's'
буквы, которые не изменены, время
вернулся к отметке 3,60, а не
постепенно, но сразу же!
в тестовых данных не было "вер"
это, другие слова "мим" в нем или любой
«Ион», который может сбить с толку
Парсер POSIX, так что я в растерянности. Низлиния: всегда тестируйте свой PCRE /
POSIX RE, чтобы найти самый быстрый! тесты
были выполнены с PHP 5.1.2 под
Windows, из командной строки. Pedro
Freire cynergi.com