<分区>
Perl 的解释器是用 C 编写的,但与 C 相比,Perl 的字符串匹配速度更快。如果我错了,有人能纠正我吗?如果这是事实,可以解释吗?
<分区>
Perl 的解释器是用 C 编写的,但与 C 相比,Perl 的字符串匹配速度更快。如果我错了,有人能纠正我吗?如果这是事实,可以解释吗?
最佳答案
Perl 确实是用 C 编写的(我想也是用 Perl 编写的)。
C 没有字符串匹配能力,所以它不可能比 Perl 慢(或快)。当然,您可以用 C 编写一个字符串匹配库并将其与 Perl 中的字符串匹配进行比较,但是您不能比较 C 的,因为 C 没有。
demerphq(Perl 的正则表达式引擎大师之一)最近回复了“P5 RE 与其他语言的其他 RE 的速度(我不会定义)是多少?”具有以下内容:
This is a tricky question. My general experience is that some regex engines match faster for some patterns, but that many regex engines fail to match slower, often much slower and that in practice perls engine is competitive or superior to many other engines. So you have to be really careful with benchmarks on this, many only look at a success cases, which Perl often is slower at. This is a deliberate design decision, in many scenarios pattern fail to match more often than they match, and generally we try to fail fast.
Another subject that makes this kind of comparison tricky is that Perls regex engine has a very rich feature set and other engines often trade features for performance. Perls regex engine has very good unicode support, support that you will often find is not supported by other engines (often this is despite their claims.)
An example of this kind of stuff is the "mandatory substring" logic that Perl uses. The engine will find the longest string in the pattern that must be present for the pattern to match. We then use Fast-Boyer-Moore (FBM) matching to determine if the string exists. If it does not then we never start the regex engine. This means that in theory Perl can reject a pattern significantly faster than a true DFA could, and that in practice it often does so. A DFA typically needs to do N operations for a string of length N, FBM can do best case N/L inspections, where N is the number of characters and L is the length of the mandatory string.
关于c - Perl 的解释器是用 C 编写的,但与 C 相比,perl 的字符串匹配速度更快,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/14456048/