mai62
Нередко одно и то же правило можно записать двояко - используя подстановочные символы или регекспы. Какой путь более эффективен?
Например:
+? или .
+pattern или pattern
Что предпочесть?
В основном встречаются два подхода - обработка простых строк непосредственно строчными ф-ями и предварительный перевод простых строк в регекспы с дальнейшей их обработкой в RegExEngine. А как это реализовано в HC?

Приветствую всех!

Несколько вопросов по оптимизации правил.

1. Имеет ли значение длина правила? Т.е. длинное или очень длинное правило отрабатывается медленнее, чем несколько коротких или это не имеет значения? Или наоборот, длинное быстрее, чем куча коротких?

2. "Обычные" правила исполняются быстрее, чем регулярные выражения, или одинаково по скорости?

3. Список правил исполняется всегда последовательно до конца (например, чёрный) или до первого сработавшего правила?

Если какие-то списки исполняются до конца, то рацпредложение: реализовать функцию, которая поднимала бы самые "популярные" правила вверх в списке и опускала редко срабатывающие к концу.
Таким образом будут экономиться ресурсы.

mai62 уже отвечал на подобный вопрос так:


От себя добавлю, что быстродействие правила зависит в большой степени не от длины, а от наличия в нем ресурсопожирающих конструкций!
Например, опытным путем уже было установлено, что:

• (.)* из-за многократной рекурсии пожирает гораздо больше ресурсов, чем просто .*
  Это иногда приводило к срабатыванию ограничения на число рекурсий и правило не работало на длинных URL!
  Да и сама конструкция .* потребляет много ресурсов, поэтому не стоит использовать ее там, где нет прямой необходимости, например, в начале и конце правил.
  
• Вместо a|c|e лучше использовать [ace] , т.к. это потребляет меньше ресурсов.
  
• Конструкция вида a{3} работает медленнее, чем aaa
  
• Надо стараться избегать лишних скобок. Например: a(bc|de) съест больше ресурсов, чем abc|ade
  и т.д.
  

В общем, если нет прямой необходимости, то надо избегать ресурсоемких конструкций!
 

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


Все списки, кроме "Переадресации" и "Преобразование URL", проверяются до первого сработавшего правила.


Такое предложение уже выносилось. Это не первоочередная задача! На данный момент в HC известно несколько других более "узких мест", прямо влияющих на производительность...


Чтобы было примерно понятно, о каких временнЫх затратах идет речь при проверке регулярных выражений приведу несколько своих замеров на Pentium-4 2.8:
^content-length: (\d*) - 0,0000111 сек
^content-length:\s*(\d*)\s*$ - 0,0000121 сек
Т.е. чуть больше 1 секунды на 100000 проверок! ИМХО, это крайне маленькая величина, чтобы бить тревогу по этому поводу!

Я говорил: "не стоит использовать ее там, где нет прямой необходимости"! В "Переадресации" и "Преобразовании URL" такая необходимость может возникнуть, а, например, в начале и конце правил "Черного списка" - нет!


В этом нет необходимости! Для работы данной опции HC будет использовать все тот же RegExp! Кроме того, я уже говорил, что разница в быстродействии не всегда столь существенна - в примере выше добавление двух похожих конструкций \s* увеличило время проверки всего на 0,000001 секунды - это мизер!

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

Впрочем, вы наглядно показали, что "работы по оптимизации" не дадут ощутимого выигрыша в случае среднего пользователя. Однако если правил очень много, всё-таки выигрыш будет.

Ясно, т.е. вы рекомендуете отключить логи и монитор для обычной работы?

Да. Много зависит от способа написания правила. Эти моменты будут особо актуальны, если НС когда-нибудь начнет фильтровать HTML-контент.
Сейчас тоже можно исполнить сильно замедляющие работу и жрущие память правила.
К примеру, задать в тренажере простейшее с виду правило
(a+)*s|N
Задать очень короткую входную строку
aaaaaaaaaaaaaaN
DenZzz
Можешь померить, за какое время сработает это правило на указанной строке? Интересно.
Если добавить в начало входной строки еще одну "a", то тренажер (или сама PCRE) уже не справится с задачей.
(Опять же, очень жаль, что тренажер нам об этом никак не диагностирует).

Да. Познавательный результат.
Если кто-то захочет добраться в УРЛе до первого знака вопроса, а если его нет, то до слэша правилом
^(\w+|[./-])*\?|/
то получит фактическое несрабатывание правила на большинстве УРЛов, хотя логически оно должно срабатывать. Для тех из них, на которых оно все-таки будет срабатывать, обработка правила будет занимать значительное время.
Вообще всегда, когда это возможно, надо избегать операций повторения над операциями повторения, а также избегать при повторениях захватов подстроки (употребления простых круглых скобок).

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

Сложно представить, что кто-то может реально использовать нечто подобное монстрообразное