Производительность регулярных выражений: Boost vs. Perl

Question

Я ищу сравнение производительности между Perl и регулярным выражением Boost.
Мне нужно спроектировать фрагмент кода, который очень сильно зависит от регулярных выражений и может выбирать между:

1. запуск через регулярное выражение Boost
2. отправка интерпретатора Perl и выполнение работы в Perl

Я знаю, что Perl известен своей оптимизированной обработкой строк. Тем не менее, я не могу найти сравнение производительности для повышения библиотеки регулярных выражений.
Знаете ли вы о таком сравнении?
Спасибо

Answer 1

Начальная стоимость запуска интерпретатора Perl из вашего приложения (я полагаю, через системную функцию) перевесит любые преимущества, которые вы получите от использования движка регулярных выражений Perl. Исключением может быть, если у вас ОЧЕНЬ сложное регулярное выражение, для которого реализация регулярного выражения в Perl оптимизирована, а движок регулярного выражения boost - нет.

Реальный ответ заключается в том, что я не знаю ни одного подобного сравнения, но средства регулярного выражения Perl не обязательно являются самыми быстрыми. См. здесь для получения некоторой информации об алгоритме, который бьет регулярное выражение Perl для некоторых выражений.

РЕДАКТИРОВАТЬ: можно преодолеть стоимость запуска запуска полного Perl-интерпретатора, связавшись с libperl или используя libPCRE . А использование boost, возможно, даст вам больше гибкости и возможностей настройки производительности, если они вам нужны.

Заключительное примечание: Нет никаких прямых прямых сравнений между boost.regex и регулярным выражением Perl с точки зрения производительности. Решение состоит в том, чтобы попробовать оба варианта и посмотреть, какой из них более эффективен для конкретной ситуации ОП.

(Edit: теперь есть хорошее сравнение между Boost и PCRE. См. http://www.boost.org/doc/libs/1_41_0/libs/regex/doc/gcc-performance.html)

Answer 2

Если вы еще этого не видели, в Great Shootout есть тест regexp. Это вообще не высоко оценивает Perl. Реализация Boost, использующая boost::xpressive, занимает первое место (что предварительно компилирует выражение во время компиляции). Однако это микробенчмарк, поэтому, вероятно, он не отражает общую скорость регулярного выражения, но все же стоит посмотреть.

Удивительно, но, пожалуй, самым быстрым механизмом регулярных выражений на сегодняшний день является JIT-код Google Chrome V8 JavaScript (почти превосходит GCC за настенное время, используя только одно ядро ​​процессора)

Answer 3

Если ваши регулярные выражения исправлены во время компиляции, вы также можете рассмотреть Boost.XPressive . Это позволяет писать регулярные выражения в качестве шаблонов выражений, которые анализируются во время компиляции.

Answer 4

Начните с самого простого решения. Решите, как быстро это должно быть для вашего приложения. Затем измерьте скорость. Если это слишком медленно, попробуйте более сложное решение. Мера снова. Повторите при необходимости.

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

Там "как можно быстрее" и "достаточно быстро для вашего приложения". Не добавляйте сложности, чтобы получить первое, если у вас уже есть второе.

Answer 5

Если ваше регулярное выражение не является безумно сложным (для которого, кстати, движок регулярных выражений perl невероятно быстр), то, как уже говорили другие, ваши накладные расходы связаны с запуском интерпретатора. С другой стороны, вы можете запустить постоянный Perl, который довольно легко предоставляет сервер регулярных выражений.

Answer 6

Если вам действительно нужно быстро, вы можете получить сопроцессор контента REGEX. Есть два, о которых я знаю. Titanic производит целый ряд процессоров. Другой сделан Cavium . И, наконец, LSI выкупила небольшую компанию и поставляет линейку процессоров сопоставления регулярных выражений .

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

Но если производительность является проблемой, вы можете попробовать их.

Answer 7

Переводчик Perl будет фиксированной стоимости. Если время, сэкономленное на прохождении ваших данных через интерпретатор, значительно превышает затраты интерпретатора (т. Е. У вас много данных), вы получите повышение производительности.

Вероятно, вам лучше всего использовать чистый C ++ здесь только из-за вызова процесса.

Извините, у меня нет данных. Рад видеть результаты ваших тестов.