概要 - 軽量・高速
軽量・高速
Gitは高速です。Gitでは、ほとんどの操作がローカルで実行されるため、どこかのサーバーと常に通信しなければならない集中型システムと比較して、速度面で大きな優位性があります。
GitはLinuxカーネル上で動作するように構築されたため、最初から大規模なリポジトリを効率的に扱う必要がありました。GitはC言語で書かれており、高水準言語に関連するランタイムのオーバーヘッドを削減しています。速度とパフォーマンスは、当初からGitの主要な設計目標でした。
ベンチマーク
一般的な操作がSubversion(CVSやPerforceに似た一般的な集中型バージョン管理システム)と比較してどうなるか見てみましょう。小さいほど高速です。
テストのため、同じアベイラビリティゾーンに大規模なAWSインスタンスがセットアップされました。両方のマシンにGitとSVNがインストールされ、RubyリポジトリがGitとSVNの両方のサーバーにコピーされ、両方で一般的な操作が実行されました。
いくつかのケースでは、コマンドが完全に一致しません。ここでは、最小公倍数で合わせようとしました。例えば、「コミット」のテストにはGitのプッシュ時間も含まれていますが、SVNでは2つのコマンドを分離できないため、通常、コミット直後にサーバーにプッシュすることはありません。
これらの時間はすべて秒単位です。
操作 | Git | SVN | ||
---|---|---|---|---|
ファイルコミット (A) | 113個の変更されたファイル(2164行追加、2259行削除)を追加、コミット、プッシュ | 0.64 | 2.60 | 4倍 |
イメージコミット (B) | 1KBの画像を千枚追加、コミット、プッシュ | 1.53 | 24.70 | 16倍 |
現在のDiff | 187個の変更されたファイル(1664行追加、4859行削除)と最終コミットのDiff | 0.25 | 1.09 | 4倍 |
最近のDiff | 4つ前のコミットとのDiff (269個の変更/3609行追加、6898行削除) | 0.25 | 3.99 | 16倍 |
タグのDiff | 2つのタグ(v1.9.1.0/v1.9.3.0)間のDiff | 1.17 | 83.57 | 71倍 |
ログ (50) | 最後の50コミットのログ (出力19KB) | 0.01 | 0.38 | 31倍 |
ログ (全て) | 全コミットのログ (26,056コミット – 出力9.4MB) | 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の時間の多くは影響を受けません。
明らかに、これらの多くの一般的なバージョン管理操作において、GitはSVNよりも1桁または2桁高速です。これはSVNにとって理想的な条件下であっても同様です。
Gitが遅くなる唯一の場所は、最初のクローン操作です。ここでは、Gitは最新バージョンだけでなく、全ての履歴をダウンロードしています。上記のグラフからわかるように、一度しか実行されない操作としては、著しく遅いわけではありません。
操作 | Git* | Git | SVN | |
---|---|---|---|---|
クローン | Gitのクローンとシャロークローン(*) vs SVNのチェックアウト | 21.0 | 107.5 | 14.0 |
サイズ (MB) | クローン/チェックアウト後のクライアント側の総データとファイルのサイズ (MB単位) | 181.0 | 132.0 |
また、Gitはプロジェクトの全履歴にわたる各ファイルの全バージョンを持っているにもかかわらず、クライアント側のデータのサイズが非常に似ている点も興味深いです。これは、クライアント側でのデータの圧縮と保存がいかに効率的であるかを示しています。