Gitについて - 小さくて、速い
小さくて、速い
Gitは高速です。Gitでは、ほぼ全ての操作がローカルで実行されるため、常にどこかのサーバーと通信する必要がある中央集権型のシステムに比べて、速度面で大きなアドバンテージがあります。
GitはLinuxカーネルで動作するように作られました。これは、Gitが当初から巨大なリポジトリを効率的に扱わなければならなかったことを意味します。GitはC言語で書かれているため、高水準言語に伴うランタイムのオーバーヘッドが削減されています。速度とパフォーマンスは、当初からGitの主要な設計目標でした。
ベンチマーク
CVSやPerforceに似た、一般的な中央集権型バージョン管理システムであるSubversionと比べて、一般的な操作がどのようになるか見てみましょう。小さいほど高速です。
テストのために、大規模なAWSインスタンスが同じアベイラビリティゾーンに設定されました。GitとSVNが両方のマシンにインストールされ、RubyのリポジトリがGitとSVNの両方のサーバーにコピーされ、両方で一般的な操作が実行されました。
いくつかのケースでは、コマンドは完全に一致しません。ここでは、最小公倍数で一致させようと試みました。例えば、「コミット」のテストにはGitのプッシュ時間も含まれています。これは、SVNでは2つのコマンドを分離できないのに対し、ほとんどの場合、コミット直後に実際にサーバーにプッシュすることはないためです。
これらの時間はすべて秒単位です。
操作 | Git | SVN | ||
---|---|---|---|---|
ファイルのコミット (A) | 変更された113ファイル(2164行追加、2259行削除)を追加、コミット、プッシュ | 0.64 | 2.60 | 4倍 |
画像のコミット (B) | 1kBの画像を1000個追加、コミット、プッシュ | 1.53 | 24.70 | 16倍 |
現在の差分 | 変更された187ファイル(1664行追加、4859行削除)と直前のコミットとの差分 | 0.25 | 1.09 | 4倍 |
過去の差分 | 4つ前のコミットとの差分(269ファイル変更/3609行追加、6898行削除) | 0.25 | 3.99 | 16倍 |
差分(タグ間) | 2つのタグ間の差分(v1.9.1.0/v1.9.3.0) | 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倍 |
Blame | 単一ファイル(array.c)の行ごとの注釈 | 1.91 | 3.04 | 1倍 |
これはSVNにとって最良のシナリオであることに注意してください。つまり、負荷のないサーバーがクライアントマシンとギガビット接続されている状態です。この接続が遅い場合、SVNのこれらの時間のほとんどはさらに悪化しますが、Gitの時間の多くは影響を受けません。
明らかに、これらの一般的なバージョン管理操作の多くにおいて、GitはSVNにとって理想的な条件下でさえ、SVNよりも1桁から2桁高速です。
Gitが遅くなる一つの点は、最初のクローン操作です。このとき、Gitは最新バージョンだけでなく、全履歴をダウンロードします。上の図でわかるように、一度しか実行されない操作としては、それほど遅いわけではありません。
操作 | Git* | Git | SVN | |
---|---|---|---|---|
クローン | Gitのクローンとシャロークローン(*) vs SVNのチェックアウト | 21.0 | 107.5 | 14.0 |
サイズ (MB) | クローン/チェックアウト後のクライアント側の全データとファイルのサイズ (MB) | 181.0 | 132.0 |
Gitがプロジェクトの全履歴にわたるすべてのファイルの各バージョンを保持しているにもかかわらず、クライアント側のデータサイズが非常に似ていることも興味深い点です。これは、Gitがクライアント側でデータをいかに効率的に圧縮・保存しているかを示しています。