在 C# 中优化 10,000 个文件中的 1000 个正则表达式搜索

本文关键字：文件正则表达式搜索 1000 优化 | 更新日期: 2023-09-27 18:34:27

给定一个文件，该文件有大约 1000 个单独的正则表达式搜索，必须应用于 10,000 个其他文件左右，我正在寻找一种很好的方法在不到一天的时间内运行。没有搜索和替换，只是直接检查匹配。我可以手动浏览并组合其中的许多，但我想知道是否有自动化工具可以做到这一点，也许甚至可以将其简化为单个搜索。

还想知道这是否也没有被问过 1000 次，但我的谷歌 foo 在这里让我失望了。

编辑：使用外部工具是可能的，但这必须通过一个脚本运行，其中1000个左右的搜索通过，所有结果都美化成一个漂亮的报告。我用 C# 完成了一些事情，但它非常慢，因此组合想法或其他使其运行更快的方法。顺便说一句，我也已经线程化了。

改进的首要位置是确保循环以正确的顺序嵌套。

遍历文件，对于每个文件，在移动到下一个文件之前尝试所有 1000 种模式。这样，您只需打开每个文件一次，而不是1000次。

第二个想法是使用像flex + yacc + bison这样的解析器生成来预编译涵盖所有模式的单个DFA（确定性有限自动机）。与整个字典的匹配可以使用trie的方式相同，与模式列表的匹配通常可以使用状态机完成，其计算量比单独匹配每个模式少得多（基本上：一个模式无法匹配的位置和方式包含有关哪些模式可能适合该区域的信息）

发现了一些有趣的东西：

这是一个正则表达式组合器，它运行一个Perl脚本来获取所有字符串并将它们放入One String中以统治它们。

当然，从我的源字符串输出的字符串长度大约为 7000 个字符，这导致 C# 的 Regex 实现在大约 1024 个字符后爆炸 - 因为 1024 个字符是任何理智的人都需要的。 2^10 在这里非常神奇。

所以谁知道组合后它是否跑得更快，因为组合失败了:)

编辑：嗯，更改了搜索字符串中的一些小东西（删除了引号上的''），然后它运行了。现在，是时候查看一个字符串的结果是否与 1000 个字符串的结果匹配了。不过，它似乎确实运行了 x10，这非常好！

我最终退后了一大步，意识到 99% 的搜索只需一点点工作即可轻松转换为直接字符串搜索，然后使用简单的每个单词哈希集搜索。我需要 GREP 的剩余搜索我留下了，它运行得很快。吻。