PHP ereg против preg

Как указал Перси, _1_ и другие многобайтовые функции ereg не устарели. - person Evernoob; 01.09.2009

PCRE быстрее, чем POSIX RE? Не всегда. В недавнем проекте поисковой системы здесь, в Cynergi, у меня был простой цикл с несколькими симпатичными функциями ereg_replace(), которые обрабатывали данные за 3 минуты. Я заменил этот 10-строчный цикл на 100-строчный рукописный код для замены, и теперь циклу требовалось 10 секунд для обработки тех же данных! Это открыло мне глаза на то, что В НЕКОТОРЫХ СЛУЧАЯХ регулярные выражения могут быть очень медленными. Недавно я решил изучить Perl-совместимые регулярные выражения (PCRE). Большинство страниц утверждают, что PCRE быстрее, чем POSIX, но некоторые утверждают обратное. Я выбрал собственные ориентиры. Мои первые несколько тестов подтвердили, что PCRE работает быстрее, но... результаты немного отличались от других, поэтому я решил сравнить каждый случай использования RE, который у меня был, в безопасном (и быстром) проекте веб-почты с 8000 строками здесь, на Cynergi, чтобы проверить это. Результаты? Неубедительно! Иногда PCRE работают быстрее (иногда более чем в 100 раз быстрее!), но иногда POSIX RE быстрее (в 2 раза). Мне все еще нужно найти правило, когда тот или другой быстрее. Речь идет не только о размере поисковых данных, количестве сопоставленных данных или «времени компиляции 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}[ \t]+[0-9]{1,2}:[0-9]{1,2}(:[0-9]{1,2})?[ \t]+[+-][0 -9]{4}/ в PCRE в 2,5 раза быстрее, чем в 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 без учета регистра /^Received[ \t]*:[ \t]by[ \t]+([^ \t]+)[ \t]/i В 30 раз быстрее, чем его версия POSIX RE! Когда дело доходит до чувствительности к регистру, PCRE до сих пор казался лучшим вариантом. Но я обнаружил действительно странное поведение ereg/eregi. В очень простой версии POSIX RE (^|\r|\n)mime-version[ \t]: я обнаружил, что eregi() занимает 3. 60 с (просто число в тестовом тесте), в то время как соответствующий PCRE занял 0,16 с! Но если я использовал ereg() (с учетом регистра), время POSIX RE сократилось до 0,08 с! Поэтому я исследовал дальше. Я попытался сделать сам POSIX RE нечувствительным к регистру. Я дошел до этого: (^|\r|\n)[mM][iI][mM][eE]-vers[iI][oO][nN][\t]*: Эта версия также заняла 0,08 с. Но если я попытаюсь применить то же правило к любой из букв «в», «е», «р» или «с», которые не изменились, время вернется к отметке 3,60 с, и не постепенно, а сразу. так! В тестовых данных не было никаких «версий», других «мимических» слов или любого «иона», который мог бы сбить с толку парсер POSIX, поэтому я в растерянности. Итог: всегда сравнивайте свои PCRE / POSIX RE, чтобы найти самый быстрый! Тесты проводились с PHP 5.1.2 под Windows, из командной строки. Педро Фрейре cynergi.com - person Benjamin Atkin; 10.07.2012