我们正试图摆脱boost :: regex，这是非常糟糕的表现。 根据{{3}}基准，this是最好的整体。
我们有多个regexp（并且总是在变化），我们应用于从中（100个字符）到巨大（1k字符）的字符串......所以这是一个非常异质的环境。
有没有人成功使用过它？您是否建议选择PCRE或RE2等更“标准”的产品？
谢谢！
答案 0 :(得分：8)
这两种实现（FSA和BT）具有完全不同的行为，您可以在右侧列（电子邮件）中看到。
oniguruma通常很快，但如果你对某个特定的正则表达式“不幸”，它有可能慢慢运行。那是因为它是一种回溯算法。 相反，虽然re2通常稍慢，但它没有相同的风险 - 它的时间永远不会[*]以相同的方式爆炸（它没有最坏情况的指数行为）。所以这取决于细节。如果您确信您的正则表达式是安全的，或者愿意检测并中止缓慢的匹配，那么oniguruma是有意义的。但就我个人而言，我倾向于为re2的安全支付更多（不多）。
有关此内容的详情，请参阅http://swtch.com/~rsc/regexp/regexp1.html（由re2作者提供）。
[*]好吧，也许永远不会太强大。对于某些正则表达式，我认为它必须依赖于针对某些情况的BT方法（可能涉及匹配先前的匹配和前瞻）。但它在大多数正则表达式上仍然更安全。
答案 1 :(得分：5)
我已经使用以下图书馆做了基准测试：
基准测试包括执行一系列测试，这些测试在非常异构regexp（分组，不分组，长字符（484个字符），短字符串，管道，\？）上大量使用正则表达式， * ,.等）。应用于从几个字符到大约8k字符的文本。
每次计算正则表达式匹配时，我都存储了正则表达式并增加了一个毫秒计数器，累计计算正则表达式所花费的时间（多次调用）。
以下是每个库的所有正则表达式所花费的总时间：
*我们（几乎）总是希望在regexp中捕获组的内容，而re2在捕获组（see here）时执行可怕的。您在上述结果中没有看到太多，因为当无法捕获该组时，它表现良好。例如在这个正则表达式上（执行了很多次）：
^((?:https?://)?(?:[a-z0-9\-]{1,63}\.)+(?:[a-z0-9\-]{1,63}))(?:[^\?]*).*$
以下是每个libs的结果：
请参阅re2的drop从5663 ms到37 ms。
所以我的结论是，对于我们的使用，Oniguruma明显优越。
但是如果你不需要捕获组，re2是一个更好的选择，因为我发现它的API更容易使用。