单令牌前瞻的性能损失是什么？

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 解析器的以下交流：Haoyi Li：在perf[ormance]方面，它可以在15秒内解析scala/scala、lift、scalaz、scalaj、playframework和shapeless中的所有东西……有谁知道在编译器和宏中有多少时间花了解析？我的印象是绝大多数时间都花在了类型检查器上。Odersky：是的，与编译器的其他任务相比，解析是非常微不足道的……也就是说，[下一代 Scala 编译器的解析器]（手写，2100 行，包括错误报告、准确位置和树构建）每秒达到几十万行。所以煮过的还有一段路要走:-)当我们谈论每秒解析的数十万行代码（包括规则 #2）时，可以推断速度不是问题。Go 编译往往以每秒20k 行左右的速度进行计时，因此即使 Go 解析花费的时间为零，并且Scala 解析的全部时间都被单行前瞻占用了，它也将少于 10% 的惩罚构建过程。实际上，它应该更像是 0%。Lookahead 通常非常便宜；你已经有了一个令牌流，所以你只需看看下一个。