Arm 效能測試

在較慢的平台上，建置系統的效能差異會更明顯。為了檢視這種差異，我們比較了 Meson 和 GNU Autotools 的效能。我們採用 GLib 軟體專案，並使用 Meson 重寫了其建置設定。之所以選擇 GLib，是因為它是一個相對較大的 C 程式碼庫，需要大量的底層組態設定。

Meson 版本的建置系統與原始的 Autotools 版本並不完全等效。它不會執行所有相同的組態步驟，也不會建置所有相同的目標。最大的缺失部分是使用 Gettext 的國際化支援。然而，它確實配置了系統，足以建置所有 C 原始碼並執行所有單元測試。

所有測量均在運行最新 Ubuntu Touch 映像檔（於 2013 年 9 月 9 日更新）的 Nexus 4 智慧型手機上完成。

測量

我們測量的第一件事是執行組態步驟所需的時間。

Meson 大約需要 20 秒，而 Autotools 需要 220 秒。這是一個數量級的差異。Autotools 的時間包含 autogen 和 configure。同樣，應該記住，Meson 並不執行 Autotools 所做的所有組態步驟。它確實執行了約 90% 的步驟，而只需要 10% 的時間。

然後我們測量了建置時間。兩個平行編譯程序用於兩個系統。

在桌上型電腦上，基於 Ninja 的建置系統比基於 Make 的快 10-20%。在這個平台上，差異增長到 50%。這種差異可能是由於 Make 的磁碟存取模式效率低下造成的。Ninja 更擅長讓兩個核心始終處於執行狀態，從而產生令人印象深刻的效能提升。

接下來，我們測量了「空建置」的情況。也就是說，建置系統偵測到不需要進行任何變更需要多長時間。這是建置系統最重要的指標之一，因為它對您迭代程式碼的速度設置了硬性限制。Autotools 需要 14 秒才能確定不需要執行任何工作。Meson（或者更確切地說是 Ninja）只需要四分之一秒。

連結是需要相當多時間的一個步驟。一個常見的情況是，您正在開發一個函式庫，並且有數十個連結到它的測試執行檔。即使編譯步驟很快，重新連結所有測試執行檔也需要時間。人們通常只會手動使用 make sometest 之類的命令編譯一個測試應用程式，而不是重新建置所有內容。

Meson 針對這種情況進行了優化。每當重新建置函式庫時，Meson 都會檢查它匯出的 ABI。如果它沒有更改，Meson 將跳過所有不必要的重新連結步驟。這種差異在上面的圖表中可以清楚地看到。在該測試中，原始碼已完全建置，然後觸摸檔案 glib/gbytes.c 以強制重新建置基本 glib 共用函式庫。如您所見，Autotools 然後會重新連結所有與 glib 連結的測試執行檔。由於 Meson 可以偵測到 ABI 是相同的，因此它可以跳過這些步驟。最終結果是，在這種非常常見的使用案例中，Meson 的速度幾乎快了一百倍。

結論

與 Java 等語言相比，C 和 C++ 的主要缺點之一是編譯時間長。然而，至少部分原因可以歸咎於所使用的建置工具，而不是語言本身或其編譯器。選擇合適的工具可以使 C 和 C++ 的編譯非常接近即時重新建置。這會直接影響程式設計師的生產力。