Java编译速度与Scala编译速度

我用Scala编程已经有一段时间了，我喜欢它，但有一件事让我很恼火，那就是编译程序所花的时间。这似乎是一件小事，但使用Java，我可以对我的程序进行一些小的更改，单击netbeans中的run按钮，然后BOOM，它正在运行，随着时间的推移，在scala中编译似乎会消耗很多时间。我听说在许多大型项目中，脚本语言变得非常重要，因为编译需要花费大量的时间，这是我在使用Java时没有看到的需求

但我来自Java，据我所知，Java比任何其他编译语言都快，而且速度快，这是因为我切换到Scala（这是一种非常简单的语言）的原因

所以我想问，我能不能让Scala编译得更快，scalac是否会像javac一样快。

使用-它是一个作为后台任务的快速Scala编译器，不需要一直加载。它可以重用以前的编译器实例

我不确定Netbeans scala插件是否支持fsc（文档中说是这样），但我无法让它工作。尝试每晚构建插件。

最新版本的（Eclipse）在管理增量编译方面做得更好

有关详细信息，请参阅“”

---

另一种解决方案是将（如本文所示）作为构建器集成到IDE中

但不是直接在Eclipse中，正如评论中提到的：

---

您不应该直接在Eclipse中使用FSC，因为Eclipse已经在表面下使用FSC了。
FSC基本上是驻留编译器之上的一个薄层，这正是Eclipse用来编译Scala项目的机制

---

最后，正如评论中提醒我的那样：

---

还包括某种“增量”编译（通过），尽管它和增强的增量编译正在为即将到来的0.9 sbt版本进行工作。

Scala编译器比Java编译器更复杂，提供类型推断、隐式转换和更强大的类型系统。这些特性不是免费提供的，所以我不希望scalac能像javac一样快。这反映了程序员和编译器之间的权衡

也就是说，编译时间从Scala2.7到Scala2.8已经有了显著的改进，我希望在2.8尘埃落定之后，这种改进还会继续。记录了为提高Scala编译器的性能而正在进行的一些工作和想法

---

我相信这一点会被否决，但极为迅速的转变并不总是有利于质量或生产力

花时间更仔细地思考，执行更少的开发微周期。好的Scala代码更密集、更重要（即，没有附带的细节和复杂性）。这需要更多的思考，这需要时间（至少一开始）。您可以通过更少的代码/测试/调试周期（单个周期稍微长一点）取得良好的进展，并且仍然可以提高生产率和工作质量

---

简而言之：寻找一种更适合Scala的最佳工作模式。

您应该知道，Scala编译至少需要比Java长一个数量级的时间来编译。原因如下：

命名约定（文件

XY.scala

文件不需要包含名为

XY

的类，并且可能包含多个顶级类）。因此，编译器可能必须搜索更多源文件才能找到给定的类/特征/对象标识符

隐式-大量使用隐式意味着编译器需要搜索给定方法的任何范围内隐式转换，并对它们进行排序以找到“正确”的方法。（也就是说，在定位方法时，编译器的搜索域大大增加。）

类型系统——scala类型系统比Java复杂得多，因此需要更多的CPU时间

类型推断-类型推断在计算上非常昂贵，而且

javac

根本不需要做这项工作

scalac

包括一个8位的全副武装作战站模拟器，可在GenICode编译阶段使用组合键CTRL-ALT-F12查看

---

最好的Scala方法是使用IDEA和SBT。设置一个基本的SBT项目（如果您愿意，它会为您做），并在自动编译模式下运行它（命令

~compile

），当您保存项目时，SBT将重新编译它

您还可以将SBT插件用于IDEA，并将SBT操作附加到每个运行配置。SBT插件还为您提供了IDEA中的交互式SBT控制台

---

无论哪种方式（外部运行SBT或SBT插件），SBT都会保持运行，因此构建项目时使用的所有类都会“预热”和JIT，并且启动开销也会被消除。此外，SBT只编译需要它的源文件。这是迄今为止构建Scala程序最有效的方法。

Scala编译器的速度（缺乏）有两个方面

更大的启动开销

• Scalac本身由许多必须加载和jit编译的类组成

• Scalac必须在类路径中搜索所有根包和文件。根据类路径的大小，这可能需要额外的一到三秒钟

总的来说，scalac的启动开销预计为4-8秒，如果您第一次运行它，则启动时间会更长，因此磁盘缓存不会被填满

Scala对启动开销的回答是使用fsc或使用sbt进行连续构建。IntelliJ需要配置为使用任一选项，否则即使对于小文件，其开销也会非常大

编译速度较慢。Scalac每秒管理500到1000行。Javac的管理能力是这个的10倍。这有几个原因

• 类型推断代价高昂，尤其是