關於 - 小巧快速
小巧快速
Git 速度很快。 使用 Git 時,幾乎所有操作都在本地執行,這使其在必須不斷與某處伺服器通信的集中式系統上具有巨大的速度優勢。
Git 的構建是為了在 Linux 核心上運作,這意味著它從一開始就必須有效地處理大型儲存庫。 Git 是用 C 語言編寫的,減少了與較高階語言相關的執行時開銷。 從一開始,速度和效能就是 Git 的主要設計目標。
效能基準
讓我們看看常見的操作如何與 Subversion(一種常見的集中式版本控制系統,與 CVS 或 Perforce 類似)相比較。 越小越快。
為了進行測試,在相同的可用區域中設置了大型 AWS 實例。 Git 和 SVN 都安裝在兩台機器上,Ruby 儲存庫被複製到 Git 和 SVN 伺服器,並且在兩者上執行了常見的操作。
在某些情況下,命令並不是完全匹配。 在這裡,嘗試匹配最低公分母。 例如,「提交」測試還包括 Git 的推送時間,儘管大多數情況下您不會在提交後立即推送至伺服器,因為在 SVN 中這兩個命令無法分離。
所有這些時間均以秒為單位。
操作 | Git | SVN | ||
---|---|---|---|---|
提交檔案 (A) | 新增、提交並推送 113 個修改的檔案 (2164+, 2259-) | 0.64 | 2.60 | 4 倍 |
提交圖片 (B) | 新增、提交並推送一千個 1 kB 圖片 | 1.53 | 24.70 | 16 倍 |
差異 當前 | 比較 187 個已變更的檔案 (1664+, 4859-) 與上次提交的差異 | 0.25 | 1.09 | 4 倍 |
差異 最近 | 比較與 4 次提交之前的差異 (269 個已變更/3609+,6898-) | 0.25 | 3.99 | 16 倍 |
差異 標籤 | 比較兩個標籤之間的差異 (v1.9.1.0/v1.9.3.0) | 1.17 | 83.57 | 71 倍 |
日誌 (50) | 最後 50 次提交的日誌 (19 kB 的輸出) | 0.01 | 0.38 | 31 倍 |
日誌 (全部) | 所有提交的日誌 (26,056 次提交 – 9.4 MB 的輸出) | 0.52 | 169.20 | 325 倍 |
日誌 (檔案) | 單一檔案的歷史記錄日誌 (array.c – 483 個修訂版本) | 0.60 | 82.84 | 138 倍 |
更新 | 提交 A 情境的拉取 (113 個檔案已變更,2164+, 2259-) | 0.90 | 2.82 | 3 倍 |
追溯 | 單一檔案的行註解 (array.c) | 1.91 | 3.04 | 1 倍 |
請注意,這是 SVN 的最佳情況 – 一個沒有負載的伺服器,並具有與客戶端機器的 Gigabit 連線。 如果連線速度較慢,幾乎所有這些時間對於 SVN 都會更糟,而許多 Git 時間則不會受到影響。
顯然,在許多這些常見的版本控制操作中,即使在 SVN 的理想條件下,Git 也比 SVN 快一到兩個數量級。
Git 速度較慢的一個地方是在初始複製操作中。 在這裡,Git 會下載整個歷史記錄,而不僅僅是最新版本。 如上圖所示,對於僅執行一次的操作而言,速度並不會明顯較慢。
操作 | Git* | Git | SVN | |
---|---|---|---|---|
複製 | Git 中的複製和淺層複製(*) 與 SVN 中的簽出 | 21.0 | 107.5 | 14.0 |
大小 (MB) | 複製/簽出後客戶端總資料和檔案的大小 (以 MB 為單位) | 181.0 | 132.0 |
同樣有趣的是,即使 Git 也擁有專案整個歷史記錄中每個檔案的每個版本,客戶端資料的大小也非常相似。 這說明了它在客戶端壓縮和儲存資料方面的效率。