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

原文链接https://medium.com/keepsafe-engineering/kotlin-vs-java-compilation-speed-e6c174b39b5d#.l8wax2t8j

译者:
昨天发表了一篇文章爽翻天!告别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一样快。

[译] Kotlin VS Java:编译速度大比拼》有6个想法

  1. Do you feel the pain of acid reflux? Do you feel a fire inside your chest? Are you miserable? Are you ready for the issues to stop? Continue reading to find out how. Keep reading to learn to control acid reflux for good and to end the misery for good.

    You may need to balance out hydrochloric acid amounts in your body if you want to reduce acid reflux and its symptoms. You can do this, for instance, by using sea salt rather than table salt. Sea salt has chloride and minerals that are good for the stomach and prevent acid.

    https://www.viagrasansordonnancefr.com/acheter-viagra-pharmacie/

发表评论

电子邮件地址不会被公开。