parsing - 解析器的性能 : PEG vs LALR(1) or LL(k)

标签 parsing parser-generator lalr ll peg

我看到一些声称优化的 PEG 解析器通常不能比优化的 LALR(1) 或 LL(k) 解析器更快。 (当然,解析的性能取决于特定的语法。)

我想知道 PEG 解析器是否有任何特定限制,无论是总体上还是对 PEG 语法的某些子集都有效,这会使它们不如 LALR(1) 或
LL(k) 性能方面。

特别是,我对解析器生成器很感兴趣,但假设它们的输出可以在任何特定情况下针对性能进行调整。我还假设解析器已经过优化,如果需要提高性能,可以稍微调整特定的语法。

最佳答案

发现一个好 answer about Packrat vs LALR parsing .一些引述:

L(AL)R parsers are linear time parsers, too. So in theory, neither packrat nor L(AL)R parsers are "faster".

What matters, in practice, of course, is implementation. L(AL)R state transitions can be executed in very few machine instructions ("look token code up in vector, get next state and action") so they can be extremely fast in practice.

An observation: most language front-ends don't spend most of their time "parsing"; rather, they spend a lot of time in lexical analysis. Optimize that ..., and the parser speed won't matter much.

关于parsing - 解析器的性能 : PEG vs LALR(1) or LL(k),我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/11373644/

相关文章:

java - 使用 DateTimeFormatter ofPattern 解析日期

ios - 解析来自 googleapi 的数据

javascript - 从 xml 中获取字符串值

rust lalrpop 词法歧义 : non-greedy matching inside of brackets

ios - Objective-C iOS 根据定义解析字符串

php - 这个文法不是LR(1)吗?

ide - 从示例数据创建解析器语法

parsing - 解析器错误恢复可以由语法自动引导吗?

java - 类似结构的源代码解析和类似宏的处理

parsing - 用于 scala 的 LALR(1) 解析器生成器