递归下降与生成的解析器 - 效率

时间:2009-01-28 14:33:25

标签: compiler-construction recursive-descent

手写递归下降解析器(不可避免地是LL(k))在性能方面与生成的LALR解析器相比如何?

我知道LALR解析器能够处理比LL(k)更多的语法;但是我打算手工编写我的解析器,递归下降似乎是最合适的选择。是否可以手工编写任何其他类型(合理可读)?

NB 我正在使用带尾调用优化(F#)的函数式语言,因此[精心定制的]递归不会像其他语言一样出现问题。

2 个答案:

答案 0 :(得分:8)

我认为很大程度上取决于您要解析的语言。性能的另一部分有时会被遗忘的是词法分析(扫描)部分 - 它对性能很重要,因为它处理字符而不是符号。递归下降是编写解析器的第一次迭代,它使得解析语言的逻辑非常自然。我认为如果解析的语言适合(没有左递归),你应该从递归下降开始。在此阶段选择LALR的性能似乎是过早的优化。 你可以手工编写chart parser,但我怀疑这是你的意思。手工编写LALR解析器是可能的,但很乏味。

答案 1 :(得分:1)

此时,性能原因在LALR和LL之间进行选择听起来像是一个过早的优化。解析时间很少是编译器的瓶颈。如果我是你,我会根据你是否更自在地自下而上或自上而下定义你的语法来做出选择。

就个人而言,我发现LALR语法易于使用,而F#的fsyacc集成(这是我学习解析的方式)使得将yacc集成到项目中变得非常容易。