我目前在 .NET 4.0 中工作我的第一个项目,它需要数千个字符串比较(我正在搜索目录,有时是整个驱动器以查找某些文件)。在大多数情况下,字符串很短,因为我只查看文件路径,所以我刚刚使用 String.Contains() 来查看文件路径字符串是否包含我的针字符串。
不过我想知道,Regex 会是一个更好的主意吗?Regex 在什么时候会比标准字符串比较快?它是基于被比较的字符串的长度还是被比较的字符串的数量?
我目前在 .NET 4.0 中工作我的第一个项目,它需要数千个字符串比较(我正在搜索目录,有时是整个驱动器以查找某些文件)。在大多数情况下,字符串很短,因为我只查看文件路径,所以我刚刚使用 String.Contains() 来查看文件路径字符串是否包含我的针字符串。
不过我想知道,Regex 会是一个更好的主意吗?Regex 在什么时候会比标准字符串比较快?它是基于被比较的字符串的长度还是被比较的字符串的数量?
如果您的搜索表达式很简单,那么我认为不值得转向正则表达式 - 无论您在编码和阅读它们方面多么出色,当您(或更重要的是,其他人)时,您将花费更多时间来理解代码) 6 个月后再看一遍。
如果速度的提高只是微不足道的,请使用更具可读性、可维护性的代码。
它是可变的。比较性能是输入数据、用于比较的文化、区分大小写和CompareOptions
. Regex 对象的实例化成本更高(除非它在Regex
缓存中),因此如果您要进行大量一次性比较,那么使用它并不是很好,而且我发现它通常比IndexOf()
YMMV 慢。
请记住,当使用 Contains/IndexOf 时,用户/线程运行的文化将决定如何进行比较。这会对性能产生重大影响。并非所有文化都一样快。
Invariant 文化是一种非常快速的文化。如果您CompareInfo
直接使用 a 而不是做String.IndexOf()
,它会更快一些。
CultureInfo.InvariantCulture.CompareInfo.IndexOf(..)
对做出正确选择有信心的唯一方法是进行基准测试。也就是说,除非您要转换数兆字节的字符串,否则对任何人都不会产生影响。正如 ChrisF 之前所说,在这种情况下,专注于可读/可维护的代码。
这是一篇关于充分利用正则表达式的好文章: 优化正则表达式性能
我只是猜测,但我怀疑对于简单的子字符串搜索String.Contains()
,String.IndexOf()
和 regex 之间的性能差别不大(如果有的话,我猜 regex 永远不会更快,但可能会慢一点)。
除非您的要求是(或成为)您需要匹配比子字符串更复杂的东西,否则您不应该考虑迁移到正则表达式。
在 .Net 4.0 中,String.IndexOf 调用存在问题,请参阅 Hotfix 2467309,它可以帮助您确定答案。