關於 - 小巧快速
小巧快速
Git 速度很快。使用 Git,幾乎所有操作都在本地執行,這使得它在需要不斷與伺服器通訊的集中式系統上具有巨大的速度優勢。
Git 是為 Linux 核心而設計的,這意味著它從一開始就必須有效處理大型倉庫。Git 用 C 語言編寫,減少了與高階語言相關的執行時開銷。速度和效能從一開始就是 Git 的主要設計目標。
基準測試
讓我們看看常見操作與 Subversion 的對比,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 來說是最佳情況——伺服器沒有負載,並且與客戶端機器有千兆位連線。如果連線速度較慢,幾乎所有這些時間對於 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 擁有專案整個歷史中每個檔案的所有版本,但客戶端資料的大小卻非常相似。這說明了它在客戶端壓縮和儲存資料的效率有多高。