每次我必须对字符串执行简单的包含或替换操作时,如果我要搜索的术语是一个固定值,我就会发现,如果我使用示例输入并对其进行一些分析,则使用编译后的正则表达式为几乎*总是比使用String类中的等效方法快。

我尝试过比较各种方法(hs是要搜索的“干草堆”,ndl是要搜索的“针头”,repl是替换值。regex始终使用RegexOptions.Compiled选项创建):

  • hs.Replace( ndl, repl )regex.Replace( hs, repl )
  • hs.Contains( ndl )regex.IsMatch( hs )

  • 我发现有很多讨论都集中在两种技术中的哪一种更快(123以及其他负载)上,但是这些讨论似乎总是着眼于:
  • 将字符串版本用于简单操作,将正则表达式用于复杂操作(从原始性能的角度来看,甚至不一定是个好主意),或者
  • 运行一个测试并比较两者(对于等效测试,正则表达式版本似乎总是表现更好)。

  • 我不明白怎么可能这样:regex引擎如何比较子字符串匹配的任何两个字符串比等效的字符串版本更快?对于很小或很大的搜索空间,或者很小或很大的搜索词,或者搜索词是早出现还是晚出现在搜索空间中,似乎都适用。

    那么,为什么是正则表达式更快?

    *实际上,只有情况,我已经设法证明,在搜索空字符串时,字符串版本比编译后的正则表达式要快!从单个字符串到很长的字符串,任何其他情况都比同等的字符串方法通过编译的正则表达式更快。

    更新:添加了一个子句来阐明我正在查看在编译时已知搜索词的情况。对于动态或一次性操作,编译正则表达式的开销将倾向于使结果偏向于字符串方法。

    最佳答案



    我可以想到两个原因:

  • 正则表达式使用诸如Boyer Moore(O(M/N))之类的智能算法,而简单的字符串操作只是将针与干草堆中的每个位置进行比较(O(N * M))。
  • 他们并没有真正在做同样的事情。例如,一个可能进行文化不变的匹配,而另一个可能进行文化相关的匹配,这可能会导致性能差异。
  • 10-05 20:43