Hello!
2013/3/3 duan yuxuan:
> 我对您开发的sregex比较感兴趣,觉得使用jit进行状态机优化的
> 设计思想很不错。
多谢鼓励 :) 不过 sregex 在设计上的主要应用场景还是大数据流的流式匹配(即非缓冲处理)。
使用 JIT 对正则引擎进行加速并不算新做法,PCRE 库官方提供 JIT 支持已经有一二年了 :)
> 但还有些不明白的地方,特向你请教以这几个
> 问题:
>
> 1)在您的介绍中,sregex支持多模匹配,我看了一下代码,没找
> 到对应的接口。请问sregex的多模匹配已经在代码中实现了吗?
>
如文档中所言,多模式匹配在代码中已经实现,ngx_replace_filter 模块也已经使用了 sregex 的这个特性:
https://github.com/agentzh/replace-filter-nginx-module
sregex 库为此主要提供了 sre_regex_parse_multi 函数,而后续的正则编译和执行匹配的 API 是相同的。
> 2)cli中提供的-n选项是指定匹配给定的若干pattern中
> 的第几个,创建的状态机只包含这个指定的模式串,也就是说其实
> 是单模,不知道这一点我理解的是否正确?
>
sregex-cli 工具的 -n <count> 选项是指定提供多少个正则表达式。
> 测试:使用一个无效的pattern
> ./sregex-cli -n 1 'a23' 'ab(' '123a23'
> 按照我的理解,'a23' 'ab(' 是模式串,'123a23'是给定的字符串。
> 这条命令可以正常执行,也就是说只处理了第一个pattern,即此刻是单
> 模匹配。
>
你的用法是错误的。正确的示例:
$ ./sregex-cli -n 2 'ab' 'a' 'ac'
...
pike match 1 (0, 1)
...
这个例子其实是用 /ab/ 和 /a/ 这两个正则同时匹配输入串 "ac". 在语义上等同于 /ab|a/ 匹配 "ac".
输出中,紧跟在“pike match”后面的正则 ID 是 1,即这里是第 2 个正则 /a/ 匹配(因为正则 ID 从 0 开始)。
$ ./sregex-cli -n 2 'ab' 'a' 'ab'
...
pike match 0 (0, 2)
...
在这个例子中则是第一个用户正则 /ab/ 成功匹配。
> 此外若果-n使用的是单模,那么thompson vm的执行结果应该和
> pike vm的执行结果一致(match/no match),但我通过cli测试,发现
> 两者的执行结果不一致:
> eg:./sregex-cli -n 1 'a23' 'abc '123a23'
>
你这个命令所执行的操作其实是使用正则 /a23/ 分别匹配两个输入串 'abc' 和 '123a23'. 在我这里执行的结是
$ ./sregex-cli -n 1 'a23' 'abc' '123a23'
...
## abc (len 3)
thompson no match
splitted thompson no match
jitted thompson no match
splitted jitted thompson no match
pike no match
splitted pike [(0, -1)] [(2, -1)] [(3, -1)] no match
## 123a23 (len 6)
thompson match
splitted thompson match
jitted thompson match
splitted jitted thompson match
pike match 0 (3, 6)
splitted pike [(1, -1)] [(2, -1)] [(3, -1)] [(3, -1)] [(3, -1)]
match 0 (3, 6)
这里前一半输出是用正则 /a23/ 匹配第一个输入串 'abc' 的结果,后一半则是用同样的正则 /a23/ 匹配第二个输入串
'123a23' 的结果。我们看到结果都是符合期望的,Thompson 和 Pike VM 的结果也是一致的。难道我漏掉什么了?
> 3)对于jit模块,目前只支持Thompson VM,您是否准备扩展到pike VM
> 上呢?
>
当然。这两个月将着手此项工作。但在此之前我将首先着手算法上的优化,比如 strchr 寻找匹配首字节的优化、DFA cache
优化、和非确定性消减优化等等。这些算法上的优化在性能提升方面比 JIT 帮助更大。
> 4)您是否测过sregex的性能,与RE2相比能提升多少(多模),sregex相比RE2,在性能上的提升除了做jit的优化外,还有其他
> 的优化吗(多模)?
>
到目前为止,sregex 尚未进入优化阶段,开发重点一直是实现功能和确保正确性。Thompson VM 的 x86_64 JIT
编译器是试验性质的,对于简单的正则,相比 gcc -O3 有大约一到两倍的性能提升。由于 sregex
在算法级别上并没有进行任何优化,所以目前在性能上和 re2 以及 PCRE JIT 还存在较大差距。
同时由于流式处理场景的特殊性,re2 使用的一些优化算法并不适用于 sregex,比如逆向匹配 DFA 以获取 submatch
capture 的起始位置的方法需要让字符串指针后退,这在流式处理模型中是不可接受的。
后续几个月中,sregex 项目的开发重点将是性能优化。
同时抄送给 openresty 中文邮件列表:http://openresty.org/#Community 由于 sregex 项目是作为
OpenResty 项目的一个相对独立的子项目开发的,所以相关的讨论放在 openresty
邮件组中也不算跑题,呵呵。也欢迎你直接在那里进行相关的交流。
Best regards,
-agentzh