Packrat 解析与 LALR 解析答案

【问题标题】：Packrat parsing vs. LALR parsingPackrat 解析与 LALR 解析
【发布时间】：2010-09-07 17:51:43
【问题描述】：

许多网站声称 Packrat 解析器可以在线性时间内解析输入。
所以乍一看，它们比 yacc 或 bison 工具构建的 LALR 解析器更快。

我想知道当使用普通输入（如编程语言源文件）而不是任何理论输入进行测试时，Packrat 解析器的性能是否比 LALR 解析器的性能更好/更差。

谁能解释这两种方法的主要区别。
谢谢！

【问题讨论】：

标签： parsing parser-generator lalr

【解决方案1】：

我不是 Packrat 解析方面的专家，但您可以通过 Parsing expression grammar on Wikipedia 了解更多信息。

我还没有深入研究，所以我假设 Packrat 解析的线性时间特征是正确的。

L(AL)R 解析器也是线性时间解析器。所以理论上，packrat 和 L(AL)R 解析器都不是“更快”的。

在实践中，重要的当然是实施。 L(AL)R 状态转换可以在很少的机器指令中执行（“在向量中查找令牌代码，获取下一个状态和动作”），因此它们在实践中可以非常快。通过将 L(AL)R 解析“编译”为机器代码，您可以得到闪电般快速的解析器，如 this 1986 Tom Pennello paper on Very Fast LR parsing 所示。（机器现在比他写这篇论文时快 20 年！）。

如果 Packrat 解析器正在存储/缓存结果，它们可能是线性时间，但我猜恒定开销会非常高，然后 L(AL)R 解析器在实践中会快得多。据我所知，YACC 和 Bison 的实现非常好。

如果您关心答案，请仔细阅读基础技术论文；如果你真的在乎，那么实现其中的一个并检查开销常量。我的钱在 L(AL)R 上。

观察：大多数语言前端不会花费大部分时间“解析”；相反，他们花费大量时间进行词法分析。优化它（你的简历说你是），解析器的速度并不重要。

（我曾经构建 LALR 解析器生成器和相应的解析器。我不再这样做了；相反，我使用 GLR parsers 在实践中是线性时间，但可以处理任意上下文无关语法。我放弃了一些性能，但是我可以 [并且确实，请参阅 bio] 为多种语言构建数十个解析器，而不会遇到很多麻烦。）。

【讨论】：

可以免费阅读文档（1986 年 Tom Pennello 的关于超快速 LR 解析的论文）吗？
当然。访问您当地大学的计算机科学图书馆：-} 我认为 ACM 只会向您收取适度的费用；恕我直言，确保 ACM 继续提供这样的东西是值得的。
@IraBaxter，L(AL)R 解析器是否像 Packrat 解析器一样无扫描？
LALR 扫描器可以是无扫描器的：只需使用语法规则定义“令牌”。如果您像 LEX/YACC 那样使用正则表达式定义标记，那么您几乎不会损失任何东西，除了性能。（你可以定义扩展正则表达式的词法分析器，例如，字符前瞻）然后你不能这样做
@Gunther：你可以看到我设法让 Paul Mann 恢复了 LRStart 站点。

【解决方案2】：

我是 LRSTAR 的作者，这是一个开源的 LR(k) 解析器生成器。因为人们对此表现出兴趣，我已将产品重新上线LRSTAR。

多年来，我一直在研究 LALR 解析器和 DFA 词法分析器的速度。 Tom Pennello 的论文非常有趣，但更多的是学术练习，而不是编译器的实际解决方案。但是，如果您只想要一个模式识别器，那么它可能是您的完美解决方案。

问题在于，现实世界的编译器通常需要做的不仅仅是模式识别，例如输入符号的符号表查找、错误恢复、提供期望列表（语句完成信息）以及构建抽象解析时的语法树。

1989 年，我将 LRSTAR 解析器的解析速度与“yacc”进行比较，发现它们的解析速度是“yacc”解析器的 2 倍。 LRSTAR 解析器使用论文中发表的思想：“Optimization of Parser Tables for Portable Compilers”。

对于词法分析器（词法分析）速度，我在 2009 年发现“re2c”生成的词法分析器速度最快，大约是“flex”生成速度的两倍。当时我正在重写 LRSTAR 词法分析器生成器部分，并找到了一种方法来制作几乎与“re2c”一样快且更小得多的词法分析器。但是，我更喜欢 LRSTAR 生成的表驱动词法分析器，因为它们几乎一样快，而且代码编译得更快。

顺便说一句，LRSTAR 生成的编译器前端可以以每秒 2,400,000 行或更快的速度处理源代码。 LRSTAR 生成的词法分析器每秒可以处理 30,000,000 个令牌。测试计算机是一台 3.5 GHz 的机器（从 2010 年开始）。

【讨论】：

请更新提供的链接。 “编译器”正在重定向； “sourceforge”没有源代码，唯一的文件下载失败。
我的拙见认为 LRSTAR 非常好。 Paul Mann 花了数年时间才做到这一点。然后，他遵循“放弃并通过服务赚钱”的行业口号，将其开源。结果他实际上饿死了；最近与他的一次谈话表明，他已将注意力转向另一个能给他带来实际回报的领域。他最后一个明显的技术行为是删除所有 LRSTAR 的公共实例。愿我们永远和 YACC 一起生活。
LRSTAR 在sourceforge.net/projects/lrstar

【解决方案3】：

[2015/02/15] 这里是 1986 年 Tom Pennello 关于超快速 LR 解析的论文

http://www.genesishistory.org/content/ProfPapers/VF-LRParsing.pdf

【讨论】：

这里的反对票是不值得的。这是一篇伟大的论文，我很高兴发帖者提供了一个链接。反对者实际上是在试图取消提供链接；那有什么意义呢？如果他们认为应该把那篇论文的一些概念放在这里，那么阅读这篇论文并写出这样的摘要，而不是抱怨别人没有这样做，对他们来说会更有建设性。

【解决方案4】：

我知道这是一个旧帖子，但是大约一个月前，我偶然发现了这篇论文：https://www.mercurylang.org/documentation/papers/packrat.pdf，今天无意中看到了这个帖子。

该论文的淡化版本说：packrat memoisation 是喜忧参半。如果您对这条或另一条规则的匹配频率有一些启发式方法，则可以获得最佳结果。本质上，记住具有以下两个属性的规则才有意义：(1) 元素少，(2) 非常常见。

【讨论】：

【解决方案5】：

性能主要是语言设计的问题。对于每种语言，都会有最适合的方法、技术或解析器生成器。

我无法不加思索地证明这一点，但我认为没有什么能比自上而下的下降解析器更胜一筹，其中语义驱动解析器，解析器驱动词法分析器，在性能方面。它也是实现中最通用且更易于维护的。

【讨论】：

LR 解析理论认为解析速度与输入的长度成线性关系。这适用于大多数上下文无关的计算机语言。所以解析速度与语言设计没有太大关系。解析速度与解析算法和解析器编写的语言有很大关系。