UNIX风格的RegExp替换在windows下运行速度极慢。帮助?编辑:影响性能的负面先行断言

Question

我尝试在1.12 GB目录中的每个日志文件上运行unix regEXP，然后用''替换匹配的模式。对一个4兆文件的测试运行花费了大约10分钟，但工作正常。显然，某些东西正在以几个数量级破坏性能。

更新:我注意到，在一个5.6MB的文件中搜索^(1550-2).*$需要大约7秒，其中包含77个匹配项。添加负的Lookahead断言，?!，使得regExp变成^(?!1550-2).*$会导致它至少需要5-10分钟；当然，将会有成千上万的匹配。

当有许多匹配时，否定的先行断言是否会对性能造成极大的损害？

Answer 1

如果你能在一开始就去掉那个.*，那将会有所帮助。它之前可以是什么，只有空格吗？如果是这样，请尝试：

^(?!\s*155[0-2][0-9]{4}\s).*$

如果它真的可以是任何东西，试着让它不贪婪：

^(?!.*?155[0-2][0-9]{4}\s).*$

注意:在这两个示例中，我删除了第二个.*，因为第三个也会匹配相同的内容。

这有助于思考正则表达式引擎将实际执行的操作。

1. 匹配^ (行首)。没问题。
2. 尝试用.*尽可能地匹配负前瞻assertion
3. Grab。这意味着它抓住了整行。
4. 是下一个字符1？如果不匹配，请使.*少匹配一个字符，并重复该操作，直到它与某个1.

匹配为止

您可以看到，这意味着对于不匹配的每一行，它将回溯到整个行。现在，如果您只在开头使用\s*，那么这将只获取空格，而不是整个行。如果真的可以，.*?在匹配155模式的行上会更快，在不匹配的行上也差不多。(在不匹配的行上，它将不断增加.*，直到它占据了整个行。)

Answer 2

基本上:您正在使用的正则表达式实现是非线性的，并且只能高效地处理正则表达式语言的一个子集。有关更多背景信息，请参阅我关于regex implementation that can handle machine generated regexes efficiently的问题。

如果你能选择另一种实现，那你就走运了；在我看的时候，这些都是稀缺的。两个合理的选项是RE2和TRE，但两者都是库，而不是独立的可执行文件。

另一种选择是使用unix实用程序(grep?)grep当然有一个windows端口，就像许多其他unix实用程序一样。