"I need performance (for 20Mb) ... so I decided Javascript". 这是矛盾的。 精心编写的递归下降解析器可以非常快,但你需要编写大量代码。通常,LALR(1)解析器(由Bison从语法生成等)非常快且很容易编码。(有技术论文展示如何将LALR解析器直接编译成机器代码;这些解析器非常快,但需要实现大量自定义机制来构建一个)。 如果你想要最大限度地提高解析性能而又不费吹灰之力,你应该考虑使用LRStar。(我认识并高度尊重作者,但与此无关)。这会产生非常快的LALR解析器。缺点是:你必须使你的语法兼容LALR。您将不得不通过编写C代码来扩展您的“规则”,就像扩展任何其他C程序一样。在我的看法中,这似乎并不比编写JavaScript更糟糕,但规则可能会执行得更快,在您考虑的规模下,这很重要。 GLR解析必然比LALR慢,因为它有更多的簿记工作要做。但那只是一个恒定因子。与LRStar等高性能引擎相比,它可能会显著(例如100倍)慢。这可能值得一试,因为将语法塑造成形状更简单,编写自定义规则也更容易。如果你真的有数百万行代码,这些解析器最多只能达到中等速度。 PEG基本上是回溯的。它必须尝试并在不起作用时回溯。它们必须比LALR解析器慢至少回溯量。您还需要解决语法塑形问题。 然而,您会发现,如果想要进行稍微复杂的任何操作,仅仅解析是不够的。在这种情况下,您不希望在解析上进行优化;您希望在程序分析基础设施上进行优化。请参阅我关于解析后的生活的文章,了解另一种选择。
我认为你没有理解我的“解析后的生活”观点。你似乎已经固定了JavaScript作为规则语言,但实际上你几乎没有任何基础设施来支持你的分析任务。因此,你可以利用一种广泛可用的编程语言来编写规则,但却没有任何支持这些规则的工具。除非你的规则基本上是微不足道的......否则这有什么意义呢?我对你的实际成功持悲观态度。 - Ira Baxter
lint
中有自定义规则,所以我肯定需要脚本语言,而JavaScript(V8 node.js实现)似乎比Python、Ruby等更快。 - shytikov