簡單比較

在這個實驗中，我們產生了一千個 C 檔案，其內容如下所示。

#include<stdio.h>
#include"header.h"

int func23() { return 0; }

每個檔案中的函數編號都不同。此外，還有一個主要的 C 檔案，它依次呼叫每個函數。然後，我們為 Meson、CMake、SCons、Premake 和 Autotools 產生了建置系統檔案，這些檔案將這些檔案編譯成單一的可執行檔。

我們以此測量了三種不同的事物。第一項是組態時間，也就是建置系統產生必要建置檔案所需的時間。這通常稱為組態步驟。時間以秒為單位測量。

第二項要測量的是建置時間。這應該受限於編譯器，並且在最佳情況下，每個建置系統應該都相同。此測試使用了四個並行處理程序。

我們測量的第三項是空的建置時間。這測量了建置系統檢查所有原始碼檔案狀態所需的時間，因為它們中的任何一個都可能導致重新建置。

由於 CMake 有兩個不同的後端，Make 和 Ninja，我們在兩者上都執行了測試。所有測試都在 2011 年的 MacBook Pro 上執行，該筆電執行 Ubuntu 13/04。測試執行多次，我們總是取最快的時間。

以下是組態時間的結果。

SCons 在此測試中獲得零秒的原因是您無法分離組態和建置步驟。它們作為一個單位執行。Autotools 明顯是此測試的輸家，因為它比第二慢的慢了一個數量級以上。此組態時間包括 autogen 和組態。所有其他系統執行此設定的時間都不到一秒，這對於人類來說足夠快到可以解釋為瞬時。

建置時間比較平均。SCons 最慢，比第二慢的慢了將近十秒。部分原因是來自組態步驟的工作，但它的效能仍然最差。Premake 是最快的基於 Make 的建置系統，僅僅擊敗了 Autotools。兩個基於 Ninja 的建置系統都比所有非 Ninja 的建置系統快，Meson 略快。實際上，差異很小。透過比較 CMake 在使用 Make 或 Ninja 時的時間，可以看出 Ninja 的優勢。僅透過變更後端，就有可能減少 3.5 秒（超過 20%）的總建置時間。專案的 CMake 組態檔案不需要任何變更。

空的建置時間反映了常規建置時間的效能。SCons 再次是最慢的，需要超過三秒的時間，而 Meson 僅需要 0.03 秒，相差兩個數量級。即使是最快的基於 Make 的系統 Autotools 也慢了將近一個數量級。Ninja 就像在先前的測試中一樣，佔據了榜首。

結論

建置系統效能很重要。即使使用這個極其簡單的範例，我們也能發現各種熱門建置系統之間的差異。隨著專案規模的增加，這些差異會變得更大。（作者曾經看到編譯 Clang 編譯器時，Make 的無操作建置時間為 30 秒，而 Ninja 的無操作建置時間不到一秒。）保持增量建置時間較短是程式設計師生產力的主要關鍵之一，因為它允許開發人員更快地迭代並保持在創造性區域中。

原始腳本

想要自行執行這些實驗的人可以在這裡下載腳本

• 產生器腳本
• 測量腳本