Мне нравится микрорайон «Царицыно», куда мы с женой переедем уже в следующем году. Нравятся все инициативы застройщика — по благоустройству района, страхованию и так далее, не нравится когда меня обманывают.

Последняя новость — застрощик организует пешеходную трассу до ближайшего метро:

Партнерами было принято решение организовать дополнительный пешеходный переход, лестницу с выходом с ул. Липецкая на Каспийскую улицу, а так же разработать комплекс других мер, позволяющих оптимизировать пешеходный путь от мкр. «Царицыно» до станции метро «Царицыно».

(…) После реализации проекта, для пешеходов время в пути от мкр. «Царицыно» до станции метро «Царицыно» составит 15 минут. То есть, отныне метро будет находиться в пешеходной доступности для владельцев квартир в мкр. «Царицыно».

Есть такие «Методические рекомендации по регулированию пешеходного движения», указания 1977 года, но не думаю, что с тех пор скорость пешехода выросла. Из него следует, что средняя скорость движения пешехода по тротуару — 1,25 м/c, впрочем, там ещё есть скорость движения по наземному пешеходному переходу — 1,4 м/c. Возьмём эту цифру.

«Яндекс.Карты» сообщают нам, что от корпуса №8 в районе застройки, до ближайшей точки входа метро «Царицыно» — 1,831 километр. По прямой!.

Нехитрые вычисления: 1831 / 1,4 = 1307,86 секунд или 22 минуты. Двадцать две минуты только по прямой, да ещё и довольно бодрым шагом. Я очень сомневаюсь, что застройщик сможет обеспечить пешеходов прямой, как стрела, дорогой до метро. Скорее всего, дорога до метро займёт от получаса, а это уже совсем другая цифра.

Много читал с утра о библиотеках регулярных выражений. Хочется найти такую, чтобы работала с UTF-8, была быстрой и мощной. Без особой надежды поискал в интернете обзоры библиотек и нашёл статью «Benchmark of Regex Libraries».

Автор сравнивает по скорости обработки три регулярных выражения, правда довольно несложных, на приличного объёма тексте. Но даже и на этих несложных регулярках есть явные аутсайдеры — например, Python (хотя другие тесты дают другие результаты).

Жалко автор не составил такую же таблицу для режима UTF-8, там производительность может сильно отличаться.

Например, мне из таблицы понравилась библиотека RE2, она показывает хорошие результаты, при этом в последнем тесте вырывается далеко вперёд. Правда в ней не реализована часть синтаксиса (например, нет backreferences), но это я бы пережил. А вот насколько она эффективная в режиме UTF-8 — вопрос (вопрос тем более актуален, что библиотека показывает примерно равную с PCRE эффективность, а PCRE с UTF-8 работает медленно).

Кстати, скрипты для тестирования доступны для скачивания. Можно попробовать переключить пару библиотек в UTF-8 и посмотреть что с ними будет.

Добавлено позднее: раз доступны скрипты тестирования, я решил посмотреть не находится ли уже RE2 в режиме UTF-8 (у неё это режим по-умолчанию), оказалось, что находится:

RE2 p(argv[1]);
buf = (char*)calloc(BUF_SIZE, 1);
while (fgets(buf, BUF_SIZE - 1, stdin)) {
        ++l;
        for (q = buf; *q; ++q); if (q > buf) *(q-1) = 0;
        if (RE2::PartialMatch(buf, p))
                printf("%d:%sn", l, buf);
}
free(buf);

Чтобы выключить режим UTF-8, нужно использовать константу RE2::Latin1, а её в коде нет. Значит, RE2 работает в режиме UTF-8. Интерееесно.

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

Как я уже писал, мне понравилась библиотека RE2, я даже скомпилировал её и посмотрел, к сожалению, оказалось, что она использует треды, а в PHP с этим не очень (не все модули PHP thread safe, поэтому чаще всего PHP собирается без поддержки тредов).

Я уже начал смотреть другие библиотеки, когда Алексей Захлестин напомнил мне про модуль PHP Multibyte String (функции mb_*), который содержит в себе движок регулярных выражений Oniguruma.

Я всегда плохо относился к этому движку, так как считал, что у него очень бедные возможности для работы с UTF-8, так как там не работают \p, \P и есть ещё пара недостатков (возможно они имеют место из-за того, что в PHP используется версия 4.7.1, тогда как последняя 5.9.2).

Сегодня я присмотрелся к движку получше. Конечно, PCRE он не заменит, но некоторых случаях вполне сможет его подменить как быстрый аналог, только надо применять несколько правил (речь идёт о версии 4.7.1, которая в PHP):

Во-первых, модификатор „i“ не действует ни на какие буквы, кроме латинских, я перебрал весь Unicode, чтобы в этом убедиться.

Во-вторых, \b и \B внутри […] относятся к backspace, а не к word boundary, а \h и \H к hex digit, а не к horizontal whitespace.

В-третьих, не работают \p и \P, зато (хоть какая-то замена) с UTF-8 работают :…: (всякие там :space: и прочие).

В-четвёртых, есть синтаксис [a-w&&[^c-g]z], то есть «&» надо экранировать внутри диапазонов.

В-пятых, части синтаксиса PCRE просто нет, например, нет рекурсии, условных регулярок, но тут уже надо обращаться к документации.

Я погонял тесты, сравнивал PCRE в режиме полном UTF-8 (с «глаголом» UCP) и Oniguruma, по результатам последний в 4…4,5 раза быстрее:

bolk-dev ~/regexp-benchmark $ php test.php
PCRE Full UTF-8: 1.0458080768585
Oniguruma:         0.24942803382874