单个令牌前瞻的性能损失是多少？

Question

当比较Go和Scala语句检测结束时,我发现Scala的规则更丰富,即:

除非满足下列条件之一,否则行结尾将被视为分号:

• 有问题的行以单词形式结束,作为语句的结尾不合法,例如句点或中缀运算符.
• 下一行以一个无法启动语句的单词开头.
• 该行在括号(...)或括号[...]内结束,因为它们无论如何都不能包含多个语句.

来自Scala的引用- 分号推断的规则.

规则#1也是Go的工作原理.规则#3也是.唯一的区别是规则#2 - 它涉及单一前瞻,因为涉及一个令牌("单词").

问题 - 涉及什么样的性能损失:1%慢,5%,10%？

我很乐意看到评论(不是问题)Go设计师为什么会忽略这个规则 - 如果不是为了表现,它会使语言更可靠,例如在方法链中:

x = some_object.select(...)
               .sort(...)
               .reverse(...)
               .where(...)
               .single()

如果我没有被误认为Go这是一个错误(你可以用两种可能的方式解决它 - 将括号中的整个语句或括号中的表达式,但它是手动调整),Scala将采取它应有的方式.

Answer 1

与编译器必须执行的所有其他操作相比,性能损失完全可以忽略不计.Scala-internals邮件列表在Haoyi Li和Martin Odersky之间进行了以下交换,关于Haoyi为Scala写的一个parboiled2解析器:

蚝李:在PERF [ormance],它可以解析方面都在阶/阶,电梯,scalaz,scalajs,playframework并在15秒无形....有谁知道多少时间在编译和宏是花了解析？我的印象是,绝大多数时间都是在类型检测器中度过的.

Odersky:是的,与编译器的其他任务相比,解析非常微不足道......也就是说,[下一代Scala编译器的解析器](手写,2100行,包括错误报告,准确位置和树构造)每秒达到数十万行.如此预感还有一些方法可以击败那个:-)

当我们谈论每秒解析数十万行代码(包括规则#2)时,可以推断出速度不是问题.Go编译往往以每秒大约20k行的速度进行计时,因此即使Go解析占用零时间,并且Scala解析的整个时间都被单行前瞻占用,它也不到10%的惩罚.构建过程.

实际上它应该更像是0%.Lookahead通常很便宜; 你已经有一个令牌流,所以你只需看看下一个.