中企动力 网站价格,机械加工网厂,展会广告策划公司,企聚网站建设原文#xff1a; A comparison of regex engines – Rust Leipzig
引言
正则表达式#xff08;或简称regex#xff09;通常用于模式搜索算法。 有许多不同的正则表达式引擎提供不同的表达式支持、性能约束和语言绑定。 基于 John Maddock 之前的工作 (regex comparison)和…原文 A comparison of regex engines – Rust Leipzig
引言
正则表达式或简称regex通常用于模式搜索算法。 有许多不同的正则表达式引擎提供不同的表达式支持、性能约束和语言绑定。 基于 John Maddock 之前的工作 (regex comparison)和 sljit 项目 regex comparison这里概述下几个活跃开发的引擎的性能。 搭建测试
硬件
这里的性能仅在我的戴尔笔记本上测试。它并不是最新的但这并不重要因为我对所有引擎使用相同的硬件并且我对不同引擎性能比较的结果感兴趣。 这里是硬件信息
Chassis: Dell Latitude E7450CPU: Intel® Core™ i5-5300URAM: 16GBSSD: Samsung PM85 256GB
软件
这里并非使用最新的软件但也比 Ubuntu 16.04 系统默认的软件包更新了
GCC 6.2.0Rustc 1.16.0 and 1.17.0-nightly
我想知道用不同引擎匹配以下每一项的执行时间:
Twain(?i)Twain[a-z]shingHuck[a-zA-Z]|Saw[a-zA-Z]\b\wnn\b[a-q][^u-z]{13}xTom|Sawyer|Huckleberry|Finn(?i)Tom|Sawyer|Huckleberry|Finn.{0,2}(Tom|Sawyer|Huckleberry|Finn).{2,4}(Tom|Sawyer|Huckleberry|Finn)Tom.{10,25}river|river.{10,25}Tom[a-zA-Z]ing\s[a-zA-Z]{0,12}ing\s([A-Za-z]awyer|[A-Za-z]inn)\s[][^]{0,30}[?!\.][\]\u221E|\u2713\p{Sm}
也许以上表达式集合不够代表性但也足以提供一个参考.
为了测量性能我修改了 sljit 项目现有的基准测试工具。 该工具可在 github 上找到 regex-performance. sljit 项目的基础工具已经支持以下正则表达式引擎
Oniguruma, v6.1.3RE2TrePCRE2, v10.23
这里我多加2种引擎:
Hyperscan, v4.4.1Rust regex crate, v0.2.1
PCRE2 Perl 兼容正则表达式 (PCRE) 是一个正则表达式 C 库其灵感来自于 Perl 编程语言中的正则表达式功能。 PCRE2 是 PCRE 库修订后的 API 的名称。 除了标准匹配算法之外PCRE2 还附带了一种基于确定性有限自动机 (DFA) 的替代算法该算法运行方式不同且不与 Perl 兼容。 手册页中提供了详细的描述。
此外PCRE2还提供了重量级优化即时JIT编译可以大大加快模式匹配速度。
为了获得可比较的结果必须使用配置选项 --enable-unicode 启用 Unicode 支持。 JIT 功能是可选的必须配合选项 --enable-jit 启用。 Hyperscan
Hyperscan 是 01.org 开源项目: Hyperscan 是一个高性能的多正则表达式匹配库。 它遵循常用的 libpcre 库的正则表达式语法但作为一个独立的库且用 C 编写了 API。Hyperscan利用混合自动机技术可以同时匹配大量的正则表达式以及在数据流中匹配正则表达式。 Hyperscan是经过10多年开发的成熟的库。Hyperscan着重的是x86平台并且该库使用硬件加速器如AVX来优化吞吐量。
默认情况下Hyperscan不考虑匹配的起始位置。要获取匹配的起始位置需要在编译模式时设置标志HS_FLAG_SOM_LEFTMOST。这个标志会带来一些性能损失但是在需要可比较结果时是必需的。
Rust 正则表达式箱
Rust 箱是“库”或“包”的同义词。Rust 正则表达式箱提供了解析、编译和执行正则表达式的函数 它的语法类似于 Perl 风格的正则表达式但缺少一些功能例如环视和反向引用。 但带来的好处是所有搜索的时间复杂度都与正则表达式和搜索文本的长度成线性关系。 除了Rust crate之外所有引擎都是使用C或C编写的包括测试工具。使用的引擎必须有C绑定因此需要一个接口来调用Rust函数。该解决方案利用Rust的FFI外部函数接口构建一个静态库该库只会计算给定表达式的匹配次数。完整的库包含3个函数总共不到50行代码。获取匹配项的主要Rust函数是
#[no_mangle]
pub extern fn regex_matches(raw_exp: *mut Regex, p: *const u8, len: u64) - u64 {let exp unsafe { Box::from_raw(raw_exp) };let s unsafe { slice::from_raw_parts(p, len as usize) };let findings exp.find_iter(s).count();Box::into_raw(exp);findings as u64
}该函数接受一个先前编译的表达式的原始指针raw_exp、一个输入C字符串的原始指针p以及输入字符串的长度len。首先函数从相应的原始指针中获取编译后的表达式和输入字符串。将原始指针转换为类型是不安全的操作因此代码部分必须用unsafe{}包装起来。然后通过调用exp.find_iter(s).count()来获取匹配项的数量。为了在后续函数调用中使用编译后的表达式再次获取表达式的原始指针。这样做的结果是在返回后表达式的生命周期仍然存在。最后该函数将匹配项的数量作为64位值返回给调用者。
对应的C函数原型是
struct Regex; // anonymous declarationextern uint64_t regex_matches(struct Regex const * const exp, uint8_t * const str, uint64_t str_len);结果
在工具构建路径执行以下命令以获取测试结果
./src/regex_perf -f ../3200.txt -o results.csv工具将细节打印如下每个引擎的结果保存到 results.csv. 最后还打印了结果的简要总结:
Total Results:
[ pcre] time: 12626.7 ms, score: 8 points,
[ pcre-dfa] time: 14135.2 ms, score: 0 points,
[ pcre-jit] time: 1050.6 ms, score: 47 points,
[ re2] time: 946.1 ms, score: 26 points,
[ onig] time: 2475.8 ms, score: 4 points,
[ tre] time: 10508.4 ms, score: 0 points,
[ hscan] time: 299.7 ms, score: 72 points,
[rust_regex] time: 3681.5 ms, score: 47 points,Timings
根据CSV文件我做了一些分析。首先我计算了每个引擎的总体执行时间。详见下图: Hyperscan是最快的引擎总执行时间约为300毫秒比第二名少约3倍而Rust的正则表达式库在排名中位列第5总执行时间约为3700毫秒。看来Rust的正则表达式库并不是最快的解决方案。
但是如果一个表达式非常慢会发生什么呢这个测试会扭曲引擎的整体结果。因此我实现了一个简单的结果评分系统。对于每个测试最快的引擎可以得到5分第二名得到4分依此类推。这限制了单个慢表达式的影响。以下图表显示了每个引擎的得分点数 Hyperscan仍然是第一名但Rust的正则表达式库与PCRE2-JIT并列第二。结果比绝对时间看起来更好但似乎有一个或多个表达式的执行时间很慢。
因此现在是时候查看每个表达式的结果了。以下图表将所有引擎每个表达式的平均时间与Rust的测量值进行了比较。次要的y轴显示了Rust值与平均值的比例以百分比表示。
. 红色曲线有3个主要的峰值即正则表达式库性能不佳的表达式。这些表达式是
[a-q][^u-z]{13}x∞|✓(?i)Twain
特别是这三个表达式中的第一个执行非常缓慢。
改进 根据基准测试的初步结果我开了一个投票 rust-lang/regex/350 来汇报我的发现以获得些反馈。Andrew Gallant化名BurntSushi给了我很好的反馈和一些改进建议。
其中一项改进是使用正则表达式库的SIMD功能。这个功能目前在Rust Nightly构建中可用因此我需要安装Nightly工具链。我调整了项目的CMake脚本以检测是否使用了Nightly编译器并支持SIMD功能。因此可以使用rustup default nightly-x86_64-unknown-linux-gnu切换Rust工具链并重新配置和构建工具以获取新的结果。 图表显示表达式∞|✓和(?i)Twain通过使用SIMD功能受益但表达式[a-q][^u-z]{13}x则不受益。这个表达式需要回溯。Rust的正则表达式库使用基于有限状态机DFA的算法缺乏反向引用和回溯功能。.
匹配
Regarding the found matches I found some deviations. At first, the libraries oniguruma and tre do not support Unicode category expressions like \p{Sm}. This expression matches all mathematical symbols like or |. The Rust regex crate matches additionally the symbol ∞.
Hyperscan returns more matches than other engines, e.g. 977 for the expression Huck[a-zA-Z]|Saw[a-zA-Z] whereas all other engines are finding 262 matches. Hyperscan reports all matches. The expression Saw[a-zA-Z] returns the following matches for input Sawyer:
从找到的匹配项中我发现了一些差异。首先oniguruma和tre库不支持Unicode类别表达式如\p{Sm}。这个表达式匹配所有的数学符号比如或|。而Rust的正则表达式库还额外匹配了符号∞。
Hyperscan返回的匹配项比其他引擎多例如对于表达式Huck[a-zA-Z]|Saw[a-zA-Z]Hyperscan返回了977个匹配项而其他引擎只找到了262个匹配项。Hyperscan报告了所有的匹配项。对于输入Sawyer表达式Saw[a-zA-Z]返回了以下匹配项
SawySawyeSawyer
其他所有引擎只报告了一个匹配项Sawy非贪婪语义或Sawyer贪婪语义。
结论
Rust正则表达式库已经推出约2年了但它趋向于超越像PCRE2和Hyperscan这样成熟的引擎。根据使用的表达式Rust正则表达式库是进行模式匹配的好选择。感谢正则表达式库的所有贡献者以及他们令人惊叹的工作。.
相关工作
regex crate包含自己的基准测试框架其中包含许多表达式并支持以下功能
PCREPCRE2RE2OnigurumaTCL
这个基准测试可以用来从另一个角度评估引擎的性能。请查看crates存储库中的bench子目录。
