C++： std::regex 比 strstr 慢 100 倍?

前言

C++11 引入正则表达式库（<regex>）以来，关于它性能的争论就没停过。 有人测试后得出结论：“std::regex 比 strstr 慢上百倍”。 甚至不少人直接在项目中禁用了 <regex>，理由只有一个——“太慢了”。

但问题真有这么简单吗？ 慢的背后，究竟是算法、实现，还是使用方式出了问题？ 今天，我们不做情绪化的结论，只讲清楚几个事实。

一、std::regex 与 strstr，不是一个层级的工具

在讨论性能前，先得搞清楚这两个函数的出发点。

1. strstr 的定位

strstr 是一个非常古老的 C 库函数，它的作用很单纯： 在一段字符串中查找另一个字符串出现的位置。

const char* p = strstr("hello world", "world");

它底层通常就是 O(n * m) 的匹配算法（不同实现会略有优化）。 这类函数的核心目标是：快。 输入是固定字符串，匹配的也是固定字符串。没有分支，没有复杂逻辑。

因此 strstr 本质上是“字符串搜索函数”，而不是“模式匹配引擎”。

2. std::regex 的定位

std::regex 是 C++11 提供的正则表达式引擎接口。 它实现了一个完整的模式匹配框架，语义上远比 strstr 复杂：

std::regex pattern("(\\w+)@(\\w+).com");
std::smatch match;
std::regex_search(text, match, pattern);

它能匹配分组、量词、字符集、环视、转义…… 而这些功能的背后，是一个完整的正则解析、编译、执行模型。

换句话说，regex 并不是“字符串查找函数”，而是一个解释器。

如果把 strstr 比作“单一指令”，那么 std::regex 就像是“执行脚本的虚拟机”。 只是这种复杂度，用户往往看不到，于是就出现了“regex 比 strstr 慢百倍”的表象。

二、慢的真正原因：编译阶段的巨大开销

几乎所有抱怨 std::regex 慢的测试，都会写成这样：

auto start = clock();
for (int i = 0; i < 10000; ++i)
    std::regex_search(text, std::regex("abc"));
auto end = clock();

问题就出在这句：std::regex("abc")。

每一次循环都重新构造一个 std::regex 对象。 而 std::regex 的构造过程并不是分配内存那么简单—— 它要经历整个“正则编译流程”：

1. 解析字符串：把 "abc" 拆分成 token。
2. 构建语法树：根据正则语法构造内部的 NFA（非确定有限状态自动机）。
3. 优化与转译：部分实现会做模式简化或状态压缩。
4. 生成执行状态机：为执行器准备匹配逻辑。

这一系列操作，在每次构造时都会发生。 而这些工作在 strstr 里根本不存在。

换句话说，很多人测试的其实是 “反复编译同一个正则的性能”， 而不是“正则匹配本身的性能”。

如果把编译阶段剔除，使用预编译好的 std::regex 对象，性能会大幅提升。

正确的用法应该是这样：

std::regex pattern("abc");
for (int i = 0; i < 10000; ++i)
    std::regex_search(text, pattern);

在这种写法下，std::regex 的慢才算进入“合理范畴”—— 它确实不如纯字符串匹配快，但差距不会夸张到百倍。

三、算法层面：NFA 与 DFA 的取舍

正则匹配的底层算法，通常分为两种路线：

C++ 标准库的 std::regex 默认使用 NFA 模型，而且是回溯式实现。 原因是：

1. 它兼容性强，能完整支持所有正则语法。
2. 不容易在状态构建阶段占用过多内存。

但问题也明显：NFA 的回溯在复杂表达式上非常耗时。 例如匹配 (a+)+b 这种嵌套量词，回溯路径会呈指数增长。

相反，像 re2（Google 的正则库）那样采用近似 DFA 模型的实现， 牺牲了一部分语法支持，却能在性能上遥遥领先。

所以慢并不是语言问题，而是“算法设计的选择”问题。 C++ 标准库选择了正确性优先，而不是性能优先。

四、C++ 标准库实现的尴尬现实

正则库的底层实现并非由标准指定，而是由编译器厂商完成。 这也意味着：不同平台的 std::regex 实现差距非常大。

1. libstdc++（GCC）

早期版本的 libstdc++ 使用的是 Boost.Regex 的移植版。 Boost.Regex 自身功能齐全，但性能并不出色。 主要原因有两个：

• 大量对象构造和内存分配；
• 复杂的状态管理机制。

这种实现导致简单的匹配操作也有不小的额外开销。 所以在 GCC 环境下，std::regex 给人的第一印象就是“慢”。

2. libc++（Clang）

Clang 的 libc++ 对正则部分做了部分重写，性能比 GCC 稍好。 但整体上仍然是以“标准兼容性”为优先目标。

3. MSVC STL

微软在 2015 之后的实现中引入了较多优化， 对常见模式的匹配路径进行了专门优化。 尽管如此，在复杂模式或频繁构造场景下，慢仍然明显。

换句话说，C++ 标准库的 regex 一直是“能用但不高效”的代名词。 这不是实现偷懒，而是受制于标准和兼容性。

五、关于编译成本的误解

很多性能测试文章都会把时间统计从构造到匹配全包进去。 这其实忽略了一个关键事实：正则编译是一次性成本。

std::regex 的设计理念是：

你定义一次模式，然后在大量文本上复用它。

标准库甚至提供了 std::regex_constants::optimize 标志， 告诉实现可以为后续匹配预先做优化。

std::regex pattern("abc.*def", std::regex::optimize);

这种优化可能包括状态表压缩、跳跃表构建等。 虽然构造会更慢，但多次匹配时性能反而更好。

如果你每次都重新 new 一个正则，那就完全背离了它的设计初衷。

这就像每次查找字符串前都重新初始化整个字典树，然后再查——当然慢。

六、复杂度的代价：功能与性能的权衡

性能差距的根本来源在于功能层级不同。

strstr 只能做一件事：查找固定子串。 regex 则要支持几乎整个正则语法体系。

比如 std::regex 需要处理以下问题：

• 转义字符处理（\d, \s, \b 等）
• 分组与捕获
• 非贪婪匹配
• 零宽断言
• Unicode 字符集兼容
• 多行模式 / 单行模式
• 回溯控制
• 匹配位置标记

这些逻辑意味着，在执行前必须先“理解”模式。 而理解的过程，就是解析、建树、生成状态机的过程。

这套机制带来的灵活性，是 strstr 无法比的。 同时也意味着，哪怕是一个最简单的 "abc"，regex 也要走完整个流程。

它不是“慢”，而是“复杂的必然代价”。

七、工程实践中的应对策略

明白原理之后，问题就简单了。 在工程中，我们并不是不能用正则，而是要用对场合。

1. 程序启动时预编译所有模式

如果匹配模式是固定的，把正则声明成 static 或成员变量。 不要在每次调用时重新构造。

static const std::regex pattern("(\\d{4})-(\\d{2})-(\\d{2})");
std::regex_match(str, match, pattern);

2. 简单匹配优先用字符串函数

判断前缀/后缀/子串出现位置，这类场景没必要上 regex。 C++17 提供的 std::string_view 与 starts_with、find 足够高效。

3. 对复杂匹配需求，可考虑替代实现

如果项目对性能有严格要求，可以引入专门的正则库，如：

• RE2（Google）
• Hyperscan（Intel）
• PCRE2（Perl兼容正则）

它们在性能和安全性上都有成熟的工业级实现。 std::regex 适合一般性处理，但不适合大规模文本处理。

八、误解的根源：测试与期望的错位

很多性能争论，其实不是算法问题，而是期望问题。

• 期望 regex 的性能像字符串函数；
• 却又要它支持复杂的语法和语义。

当这种矛盾出现时，结果自然会让人失望。

更关键的是，很多测试方式本身就存在问题。 例如将构造时间算入匹配性能、将 debug 模式的结果拿去比较、 甚至把完全不同语义的函数放在同一个基准上。

这就好比用编译器速度来评判 CPU 性能——没意义。

九、结语：慢不是问题，不理解才是

回到最初的问题：

“C++ std::regex 比 strstr 慢 100 倍？”

如果你每次都重新构造一个正则对象，那可能慢上千倍； 如果你只编译一次再多次匹配，差距可能只有个位数； 如果你理解它的设计边界，你就不会再做这种对比。

std::regex 从来不是“查字符串的快刀”， 它是 C++ 标准库为复杂模式匹配提供的一把稳重的锤。

慢，不是它的缺陷，而是它背负的重量。