概要 - 小型かつ高速
小型かつ高速
Gitは高速です。Gitでは、ほぼすべての操作がローカルで行われるため、常にどこかのサーバーと通信する必要がある集中型システムに比べて、大幅な速度の利点があります。
GitはLinuxカーネルで動作するように構築されたため、初日から大規模なリポジトリを効率的に処理する必要がありました。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) | 1キロバイトの画像を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コミットのログ(19キロバイトの出力) | 0.01 | 0.38 | 31倍 |
ログ(すべて) | すべてのコミットのログ(26,056コミット – 9.4メガバイトの出力) | 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のクローンと浅いクローン(*)とSVNのチェックアウトの比較 | 21.0 | 107.5 | 14.0 |
サイズ(MB) | クローン/チェックアウト後のクライアント側データとファイルの合計サイズ(MB単位) | 181.0 | 132.0 |
Gitにはプロジェクトの履歴全体のすべてのファイルのすべてのバージョンもあるにもかかわらず、クライアント側のデータサイズが非常に似ていることに注目することも興味深いです。これは、クライアント側でデータを圧縮して保存する効率の高さを示しています。