[譯] 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同樣快。