[译] Kotlin VS Java:编译速度大比拼

原文连接medium.com/keepsafe-en…

译者：
昨天发表了一篇文章爽翻天！告别Java。一块儿来使用kotlin开发完整客户端 评论地下出现了一些不一样的见解。这些见解、质疑都是好的，值得提倡的，由于只有这样，才能够进步，不过我以为说一个东西很差的前提是有真正了解过，使用过，而不是在没有了解到状况下听信传言。也有人提出担忧性能问题，因此找来国外一篇关于编译速度的文章。

正文：

把一个Java应用程序转换为Kotlin，编译时间要多久？

这是关于Kotlin的一系列文章。分为三个部分。 第一部分讨论了从Java转换到Kotlin。第二部分是我对Kotlin的见解。

在前面的文章中， 我讨论了把Android 应用从Java 100%转换为Kotlin 。 Kotlin代码比Java的简洁，更易于维护，因此我认为转换是值得的。 但有些人不想试用Kotlin，由于他们担忧它编译可能没有Java快。 这个关注点绝对是正确的，若是变得编译很慢，没有人愿意转换他们的代码。 因此，让咱们编译Lock App试一下 ，而后我把它转换成Kotlin。 我不会试图比较一行代码的编译速度; 相反，我将尝试回答将代码从Java转换为Kotlin是否会影响其整体构建的时间。

我如何测试构建时间

我写了一个shell来重复执行gradle。 全部测试连续进行10次。 该项目的每一个场景以前clean，并使用Gradle daemon ，daemon以前中止一次。
本文中的全部测试都在运行于3.4 GHz的Intel Core i7-6700上，使用32GB的DDR4内存和三星850 Pro SSD。 源代码是用Gradle 2.14.1构建的。

测试

我想在几种常见的使用场景中运行基准：使用和不使用Gradle daemon+clean，没有文件更改的增量编译，以及更改的文件的增量编译。
在转换以前，App Lock的Java代码有5,491个方法和12,371行代码。 改写后，这些数字降低到4,987方法和8,564行Kotlin代码。 在重写期间没有发生大的架构更改，所以在重写以前和以后测试编译时间应该很好地了解Java和Kotlin之间的构建时间的差别。

clean + 不用Gradle daemon Build

这是两种语言中构建时间最差的状况：从冷启动运行一个clean的构建。 对于这个测试，我禁用了Gradle daemon。
这里是十个构建所花费的时间：

在这种状况下的结果是，Java构建时间平均为15.5秒，而Kotlin平均为18.5秒：增长了17％。 这对Kotlin来讲并非一个好的开始，可是大部分人不会这么编译他们的代码。

对于没有Gradle daemon 而且clean构建，Java编译比Kotlin快17％

clean +Gradle daemon Build

这个JIT编译器的问题 ，就像JVM中，是它们须要时间来编译对报告的执行的代码，等等的处理随时间增长的性能，由于它运行。 若是中止JVM进程，那么性能增益会丢失。 在构建Java代码时，一般在每次构建时启动和中止JVM。 这迫使JVM每次构建时重作工做。 为了解决这个问题，Gradle附带了一个守护进程，它将在构建之间保持活跃，以便保持JIT编译的性能提高。 你能够经过在gradle命令行加参数--daemon或者在gradle.properties文件添加一句org.gradle.daemon=true。

能够看到，第一次运行所花费的时间与没有daemon的时间相同，但后续运行的性能提升，直到第四次运行。 在这种状况下，查看第三次运行后的平均构建时间更有用，其中daemon已工做过了。 对于热运行，在Java中执行clean构建的平均时间为14.1秒，而Kotlin以16.5秒的速度运行时间：多了13％。

对于clean + Gralde daemon 编译，Java编译比Kotlin快13％。

Kotlin正在遇上Java，但仍然稍微落后。 可是，不管使用什么语言，Gradle daemon都会将构建时间减小40％以上。 若是你尚未使用它，你应该用上。

因此Kotlin编译在完整代码状况下比Java慢一点。 可是你一般只会对几个文件进行更改后编译，增量构建将有不一样的性能。 因此，让咱们来看看Kotlin在增量编译是否能够遇上。

增量构建

编译器最重要的性能特性之一是使用增量编译。 正常构建将从新编译项目中的全部源文件，可是增量构建将跟踪自上次构建以来哪些文件已更改，而且只从新编译这些文件和依赖它们的文件。 这可能对编译时间有巨大的影响，特别是对于大型项目。
增量构建在kotlin1.0.2之后版本支持 ，你能够在你的gradle.properties文件添加kotlin.incremental = true实现。
那么当使用增量编译时，Kotlin与Java的编译时相好比何？ 如下是没有更改文件时使用增量编译的基准：

接下来，咱们将使用修改后的源文件测试增量编译。 为了测试这个，我在每次构建以前改变了一个java文件，Kotlin也同样。 在这个基准测试中，源文件是没有其余文件依赖的UI文件：

最后，让咱们看看使用修改的源文件进行增量编译，其中文件导入到项目中的许多其余文件

你能够看到Gradle daemon仍须要两三次运行来预热，可是以后两种语言的性能是很是类似的。 没有更改，Java每一个热创建4.6秒，而Kotlin平均4.5秒。 当咱们更改一个没有被任何其余文件使用的文件时，Java平均须要7.0秒来作一个热构建，Kotlin是6.1秒。 最后，当咱们更改项目中许多其余文件导入的文件时，Java须要7.1秒才能在Gradle daemon加热后执行增量构建，而Kotlin平均6.0秒。

在最多见的状况下 - 启用增量编译的部分构建 - Kotlin编译速度快或略快于Java。

结论

咱们对几个不一样的场景进行了基准测试，看看Kotlin在编译时间是否能够跟上Java。 虽然Java在clean构建比Kotlin 快10-15％，但这些状况不多。 对于大多数开发人员来讲，更常见的状况是部分构建，其中增量编译进行了大量改进。 随着Gradle daemon运行和增量编译的开启，Kotlin编译速度快或略快于Java。这是一个我彻底没有想到而且使人印象深入的结果。 我必须赞赏Kotlin团队设计一种不只具备不少优秀功能，并且可以快速编译的语言。若是你由于编译时试图使用Kotlin，你没必要担忧：Kotlin的编译速度和Java同样快。