为什么不用原文数据原文最大的问题不是代码写得怎样而是测试数据没有给。正则性能很吃输入分布。比如每行有多长命中比例是多少TSLA 出现在行首还是行尾不命中的行是不是有很多“差一点命中”的内容引号和转义字符有多少.*? 中间到底要跨多少字符这些东西一变结果就可能变。所以我没有试图“复现原文结果”。原文数据不公开就没法严肃复现。我这里做的是另一件事用公开、确定性的规则合成一份数据然后把所有代码放出来让别人可以重新跑。数据生成脚本在仓库里规则很简单生成约 1GB 的文本文件每行是一个 JSON string literalJSON string 里面再放一个紧凑 JSON object每 20 行放一条 TSLA也就是大约 5% 命中固定随机种子确保别人生成出来的数据一致实际这次生成的数据是bytes: 1,073,741,855lines: 4,624,532expected matches: 231,227pattern: “TSLA.*?”seed: 20260702所有实现都先把文件读进内存然后只统计内存中扫描匹配的时间。读取时间也记录了但不参与排序。测了哪些实现这次一共测了 10 个case 说明MSVC std::regex Visual Studio 18 / MSVC STLMinGW std::regex GCC 16.1.0 / libstdcPCRE2 vcpkg PCRE2 10.47PCRE2 JIT 显式 pcre2_jit_matchPython re Python 3.12.4Go regexp Go 1.26.2.NET Regex 普通 Regex构造一次复用.NET Compiled RegexOptions.Compiled构造一次复用.NET GeneratedRegex source generator 生成的正则.NET NonBacktracking RegexOptions.NonBacktracking这里有个小点要说明普通 new Regex(…) 不是每行都 new 一次而是构造一次后复用。每行都 new 那属于测错误用法不是正常业务热路径。.NET 这边大概是这样private const string Pattern “\“TSLA.*?\””;private static readonly Regex PlainRegex new(Pattern, RegexOptions.CultureInvariant);private static readonly Regex CompiledRegex new(Pattern, RegexOptions.CultureInvariant | RegexOptions.Compiled);private static readonly Regex NonBacktrackingRegex new(Pattern, RegexOptions.CultureInvariant | RegexOptions.NonBacktracking);[GeneratedRegex(Pattern, RegexOptions.CultureInvariant)]private static partial Regex InfoLineRegex();核心循环也没什么花活private static long MatchLines(string[] lines, Regex regex){long matches 0;foreach (var line in lines){if (regex.IsMatch(line)){matches;}}return matches;}C 的 PCRE2 JIT 也不是“编译了 JIT 然后还调用普通 match”这种模糊写法而是明确调用 pcre2_jit_match。完整代码直接看 GitHub 就行这里不贴一大坨了。结果每个 casewarmup 1 次正式跑 3 次只统计扫描匹配时间所有 case 匹配数都必须等于 231,227结果如下按平均耗时排序排名 实现 平均单轮扫描1 .NET GeneratedRegex 125.566 ms2 .NET Regex 170.996 ms3 .NET RegexOptions.Compiled 171.583 ms4 .NET RegexOptions.NonBacktracking 219.780 ms5 Go regexp 303.017 ms6 MSVC std::regex 448.698 ms7 PCRE2 JIT 612.498 ms8 Python re 894.424 ms9 PCRE2 5,191.270 ms10 MinGW/libstdc std::regex 26,272.900 ms.NET GeneratedRegex 三轮分别是125.294 ms125.734 ms125.669 ms这个波动很小所以至少在这份数据上不像是偶然抖出来的。另外我一开始也跑过 1MB 的小数据那个时候 .NET 没这么明显的优势。这个也正常1MB 太小了JIT、tiered compilation、缓存状态、计时噪声都能影响结果。到了 1GB 之后差距就稳定多了。有几个结果挺有意思第一.NET GeneratedRegex 真的很猛。这个结果对我来说有点爽但不是完全意外。现在的 .NET Regex 对这类模式优化得确实很激进source generator 又能把一些工作提前到编译期。这个 pattern 本身也简单本质上更接近“找一个固定前缀然后扫到后面的引号”。第二RegexOptions.Compiled 这次没赢普通 Regex。两者基本持平普通 Regex 还略快一点点.NET Regex: 170.996 ms.NET RegexOptions.Compiled: 171.583 ms所以现在写 .NET别再机械地觉得 Compiled 一定更快。很多时候你真正应该先考虑的是 [GeneratedRegex]。Compiled 不是不能用而是别把它当成无脑性能开关。第三NonBacktracking 也不等于更快。这次它是 219.780 ms比普通 .NET Regex 慢一些。NonBacktracking 的重点是避免灾难性回溯、提供更稳的线性行为不是承诺所有正则都更快。第四PCRE2 JIT 这次没有赢。这和很多人的直觉可能不一样。PCRE2 JIT 很强但不是每个 pattern、每份数据都会碾压。这个 case 里 .NET 的路径显然更适合。这里我也特意检查了一下免得变成“JIT 其实没开”的低级问题PCRE2 用的是 8-bit APIpcre2_compile、pcre2_jit_compile、pcre2_match_data_create_from_pattern 都在计时循环外JIT case 检查了 pcre2_jit_compile 的返回值失败会直接报错真正扫描时调用的是 pcre2_jit_match不是普通的 pcre2_match。所有实现也都是逐行 IsMatch/search不是某些实现扫全文件、某些实现逐行扫。所以 PCRE2 JIT 输给 MSVC std::regex 这件事我也觉得值得多看一眼但目前看不是因为测试代码把 JIT 写错了。更可能是这个 pattern 和这份数据刚好不在 PCRE2 JIT 最舒服的区间。第五MinGW/libstdc 的 std::regex 还是那个味。1GB 单轮 26 秒多。这个结果非常突出突出到我都检查了好几遍匹配数。最后所有实现匹配数一致所以至少这个 case 下它确实很慢。怎么复现仓库
