Производительность регулярных выражений: Boost vs. Perl
/(.*)<FooBar>/s
s вызывает Dot (.) для соответствия возврату каретки
6 ответов
Стоимость запуска интерпретатора Perl изнутри вашего приложения (через системную функцию, как я полагаю) перевесит любые преимущества, которые вы получите по сравнению с использованием механизма регулярных выражений Perl. Исключением может быть ОЧЕНЬ сложное регулярное выражение, для которого реализация регулярных выражений Perl оптимизирована, а механизм регулярных выражений boost - нет.
Настоящий ответ заключается в том, что я не знаю ни одного такого сравнения, но регулярное выражение Perl объекты не обязательно самые быстрые. См. здесь для получения некоторой информации об алгоритме, который превосходит регулярное выражение Perl для некоторых выражений.
РЕДАКТИРОВАТЬ: можно преодолеть начальные затраты на запуск полного интерпретатора Perl, связавшись с libperl или используя libPCRE . А использование boost, вероятно, даст вам больше гибкости и возможностей настройки производительности, если они вам понадобятся.
Заключительное примечание: нет известных прямых сравнений между boost.regex и Perl regex с точки зрения производительности. Решение состоит в том, чтобы попробовать оба и посмотреть, какой из них более эффективен для конкретной ситуации OP.
(Edit: теперь есть хорошее сравнение между Boost и PCRE. См. http://www.boost.org/doc /libs/1_41_0/libs/regex/doc/gcc-performance.html)
Если ваши регулярные выражения исправлены во время компиляции, вы также можете рассмотреть Boost.XPressive . Это позволяет писать регулярные выражения как шаблоны выражений, которые анализируются во время компиляции.
Если вы еще не видели его, есть regexp в тесте Great Language Shootout . Он вообще не ставит Perl очень высоко. Реализация Boost с использованием boost :: xpressive занимает первое место (которое предварительно компилирует выражение во время компиляции). Однако это микробенчмарк, поэтому он, вероятно, не отражает общую скорость регулярных выражений.
Если ваше регулярное выражение не является безумно сложным (для которого механизм регулярных выражений Perl, кстати, невероятно быстр), тогда, как говорили другие, ваши накладные расходы связаны с запуском интерпретатора. С другой стороны, вы можете легко запустить постоянный Perl, который предоставляет сервер регулярных выражений.
Начните с самого простого решения. Решите, насколько быстро это должно быть для вашего приложения. Затем измерьте скорость. Если это слишком медленно, попробуйте более сложное решение. Измерьте еще раз. При необходимости повторите.
Хотя мое чутье согласуется с большинством других ответов, в которых говорится, что запуск интерпретатора будет дороже, вы никогда не узнаете, пока не выполните измерения.
Есть «самый быстрый» и «достаточно быстрый для вашего заявление". Не усложняйте первое, если второе у вас уже есть.
Стоимость интерпретатора perl будет фиксированной. Если время, сэкономленное за счет обработки ваших данных через интерпретатор, значительно превышает затраты на интерпретатор (т. Е. у вас много данных), у вас будет прирост производительности.
Вероятно, вам здесь лучше всего подходит чистый C ++ только из-за вызова процесса.
Извините, у меня нет данных. Тем не менее, приятно видеть результаты ваших тестов.