Сравнительный замер с VBScript

[tormozit]

Хотелось бы увидеть сравнительные с VBScript замеры по скорости работы в клиентском и серверном коде.

[alexkmbk]

@tormozit Не могу поручиться за 100% достоверность тестов, но те тесты что я делал, показывают что скорость работы зависит от размера анализируемого текста. Если за один вызов передается сразу большой текст, то компонента работает быстрее, если же делаются частые поиски в небольших по размеру строках, то "VBScript.RegExp" работает быстрее. Основная причина на мой взгляд в том, что у платформы высокие накладные расходы на вызов функций из внешних компонент по протоколу Native API. Поэтому, исходя из вышесказанного, я бы рекомендовал использование данной компоненты в тех случаях, когда нет возможности использовать "VBScript.RegExp".

[tormozit]

Из-за использования однопоточных COM апартаментов VBScript в серверном коде работает в 20 раз медленнее чем на клиенте. Поэтому интересует сравнение именно в серверном коде.

[alexkmbk]

Из-за использования однопоточных COM апартаментов VBScript в серверном коде работает в 20 раз медленнее чем на клиенте. Поэтому интересует сравнение именно в серверном коде.

Понял, надо будет еще перепроверить.

[alexkmbk]

Из-за использования однопоточных COM апартаментов VBScript в серверном коде работает в 20 раз медленнее чем на клиенте. Поэтому интересует сравнение именно в серверном коде.

Делал замеры. Тут конечно многое зависит от того какой именно сценарий работы с регулярными выражениями используется (размер анализируемых данных, как именно обрабатываются результаты). На том скрипте, который вы прилагали в другом issue, я получил следующие результаты (вычисления выполнялись в цикле, на строке размером 9KB): На файловой базе, в серверном контексте VBScript был в 3 раза быстрее. На файловой базе, в клиентском контексте VBScript был в 3 раза быстрее. На клиент-серверной базе, в серверном контексте VBScript был примерно 2-2.5 раза медленнее (на небольшой строке, в несколько слов VBScript был в 1.5-1.6 раза медленнее). На клиент-серверной базе, в клиентском контексте VBScript был примерно в 2.5 раза быстрее. (на небольшой строке, в несколько слов VBScript был в 30 раз быстрее!). При этом я в тестах пробовал параллельно запускать выполнение кода, в 20 фоновых заданиях. Увеличение числа фоновых заданий на результаты существенно не повлияли.

Основная задержка при использовании внешней компоненты получается из-за крайне медленной работы платформы по протоколу NativeAPI. Любой, даже пустой вызов метода, в котором вообще ничего не выполняется (в самой компоненте стоит заглушка еще на этапе вызова FindMethod), происходит медленнее чем вызов VBScript. Соответственно чем чаще вызываются методы из внешней компоненты, тем хуже будут результаты и наоборот.

[alexkmbk]

@tormozit Исходя из вышесказанного, в клиентском контексте или на файловой базе под Windows, лучше использовать VBScript, в остальных сценариях, оправдано использовать внешнюю компоненту.

[tormozit]

Можно попробовать для требовательных к производительности задач сделать следующее

1. Во внешней компоненте добавить метод ПолучитьПолныйРезультатJSON, куда бы она сразу весь результат передавала.
2. Сделать парную внешнюю обработку, которая бы дублировала интерфейс внешней компоненты, но не тупо переадресовывала вызов в ВК. Там где возможно, она сначала бы получала полный результат через метод ВК.ПолучитьПолныйРезультатJSON() и затем его десериализовывала в структуры 1С и уже из них вычисляла результаты остальных функций. Так будет и проще сделать полную имитацию интерфейса VBScript и работать думаю будет сопоставимо быстро.

п.1 жду от тебя п.2 имеет смысл тебе сделать хоть в каком то виде в качестве примера, а я для себя сделаю сам полную имитацию интерфейса VBScript

[alexkmbk]

@tormozit В ходе тестов выяснил что все таки кроме расходов на протокол NativeAPI, в данном сценарии, основную задержку в работе компоненты вносит сама библиотека boost::regex. Думаю о том, чтобы перейти на библиотеку pcre2. Она по предварительным тестам показывает существенно лучшие результаты, и думаю в большинстве случаев будет работать по крайней мере не медленнее чем VBScript, а во многих случаях и гораздо быстрее. А под другие платформы выигрыш должен быть еще больше, поскольку pcre2 не требует преобразований UTF16->UTF32.

[alexkmbk]

@tormozit Опубликована тестовая версия на движке pcre2 - https://github.com/alexkmbk/RegEx1CAddin/releases/tag/13.0 Эта версия для ознакомления и тестирования. На этой версии, уже нет тех провалов в производительности когда на некоторых сценариях VBScript мог быть быстрее в 30-40 раз. Под Linux увеличилась производительность на твоем шаблоне в 5 раз.

[tormozit]

О каком моем шаблоне речь? Об этом https://github.com/alexkmbk/RegEx1CAddin/issues/8 ?

[alexkmbk]

О каком моем шаблоне речь? Об этом #8 ?

да

[alexkmbk]

@tormozit Сергей, в принципе я задачу по сериализации в json себе поставил. Но давайте посмотрим на ваш кейс, судя по вашему шаблону вам необходимо анализировать тексты модулей 1С. Тексты модулей относительно большие (по нескольку сотен строк и более) и в этом сценарии уже сейчас (после перехода на движок pcre2) внешняя компонента должна давать результат как минимум не хуже чем VBScript (а на сервере в несколько раз быстрее). Попробуйте сами протестировать на реальном сценарии, с реальными модулями из конфигураций 1С. Кстати, в вашем примере https://github.com/alexkmbk/RegEx1CAddin/issues/8 идет обращение к 7-ой и 8-ой подгруппе результатов, но в самом шаблоне только 6 групп, и обращение к несуществующим группам из внешней компоненты также дает ощутимое замедление (там формируется текст ошибки), если это убрать, то и результат замеров меняется.

[tormozit]

Мой пример демонстрирует средний уровень сложности и характер выражений, которых более сотни и решают они сотни разных задач от частого одиночного поиска короткой строки до многостадийного разбора огромных текстов модулей 1С. Этот пример является вырезкой и упрощением рабочего кода и потому не проходил тестирование на логическую корректность. Так как регулярных выражений у меня очень много, то тестировать их все нереально. Поэтому кроме скорости мне важна и совместимость с VBScript. Метод ПолучитьПолныйРезультатJSON решит для меня проблему скорости, т.к. вся ответственность за нее перейдет на мою сторону. А вот проблему совместимости с VBScript пока непонятно как решать.

[alexkmbk]

@tormozit Пониятно. При разработке всех этих сотен шаблонов наверняка значательная их часть тестировалась на regex101.com, если так, то можно с высокой долей вероятности утверждать что совместимость должна быть, по крайней мере на движке pcre2.

[tormozit]

наверняка значательная их часть тестировалась на regex101.com

=) Странное предположение. Будь это так, то получается я умышленно скрыл это, чтобы неоправданно мучать тебя. Это не так. До сих пор лучшим отладчиком регулярных выражений по моему мнению является RegexBuddy. Именно он позволил отладить самые сложные случаи с учетом всех особенностей VBScript (наборы особенностей там называются "flavor"). Но в первую очередь я большинство выражений тестировал своим конструктором http://devtool1c.ucoz.ru/index/konstruktor_reguljarnogo_vyrazhenija/0-60 , который работает именно на VBScript и позволяет создавать и удобно редактировать очень сложные иерархические выражения. Тем самым я сразу избавил себя от скрытых изменений логики работы выражений при переносе их из конструктора/отладчика в конечное место.

[alexkmbk]

@tormozit есть мнение что VBscript по синтаксису соответствует JavaScript(ECMA). Отличия между ECMA и PCRE известны - https://gist.github.com/CMCDragonkai/6c933f4a7d713ef712145c5eb94a1816

Кстати там же написано что RegexBuddy использует JGsoft и также можно сравить с PCRE.