Question

一些示例代码。这是使用cregex_iterator的c ++ 11部分：

std::chrono::steady_clock::time_point begin4 = std::chrono::steady_clock::now();
const char *pError = NULL;
int errOffset;
int options = PCRE_MULTILINE | PCRE_CASELESS;
const char* regexp = "<option[\\s]value[\\s]*=[\\s]*\"([^\">]*)\"[\\s]*[^>]*>";
pcre* pPcre = pcre_compile(regexp, options, &pError, &errOffset, 0);                
int offset = 0;
int matches = -1;
int pMatches[6];
while (offset < input_length)
{
    matches = pcre_exec(pPcre,NULL, input, input_length, offset,0, pMatches,6); 
    if (matches >= 1)
    {
        found++;
        offset = pMatches[1];
        if (found < 10000) continue;
        break;  // find match
    }
    else
        offset = input_length;
}

std::chrono::steady_clock::time_point end4 = std::chrono::steady_clock::now();

这是pcre部分。正则表达式完全相同。

JSONObject

结果显示pcre比c ++ 11快100倍。我发现了一些矢量副本并在c ++ 11实现中调整大小。还有其他一些原因吗？

Answer 1

PCRE受益于一些称为启动优化的优化，这些优化配置为默认启用。这些优化包括：

主题预扫描未锚定的模式（如果起始点是没找到引擎甚至懒得经过匹配过程。）
研究模式以确保主题的最小长度不短于模式本身
自动possessification
快速失败（如果特定点是没找到引擎甚至懒得经过匹配过程。）

表面模式分析：

<option             # Subject pre-scan applied (unachored pattern)
    [\\s]
    value
    [\\s]*          # Auto-possessification applied (translates to \s*+)
    =
    [\\s]*          # //
    \"([^\">]*)\"   
    [\\s]*          # //
    [^>]*
>                   # Min length (17 chars) check of subject string applied

此外，如果输入字符串没有像>这样的特殊字符，则应该抛出快速故障。您应该知道性能也可能依赖于输入字符串。

运行以下模式：

(*NO_AUTO_POSSESS)(*NO_START_OPT)<option[\s]value[\s]*=[\s]*\"([^\">]*)\"[\s]*[^>]*>

在这个输入字符串上（观察那段时间）：

<option value                                                                 .

并比较结果（Live demo）。

为什么pcre正则表达式比c ++ 11正则表达式快得多

1 个答案:

表面模式分析：