Gitについて - 小さくて、速い

  1. ブランチとマージ
  2. 小さくて、速い
  3. 分散管理
  4. データの保証
  5. ステージングエリア
  6. フリーなオープンソース
  7. 商標

小さくて、速い

Gitは高速です。Gitでは、ほぼ全ての操作がローカルで実行されるため、常にどこかのサーバーと通信する必要がある中央集権型のシステムに比べて、速度面で大きなアドバンテージがあります。

GitはLinuxカーネルで動作するように作られました。これは、Gitが当初から巨大なリポジトリを効率的に扱わなければならなかったことを意味します。GitはC言語で書かれているため、高水準言語に伴うランタイムのオーバーヘッドが削減されています。速度とパフォーマンスは、当初からGitの主要な設計目標でした。

ベンチマーク

CVSやPerforceに似た、一般的な中央集権型バージョン管理システムであるSubversionと比べて、一般的な操作がどのようになるか見てみましょう。小さいほど高速です。

コミットA
git
svn
コミットB
git
svn
差分(現在)
git
svn
差分(過去)
git
svn
差分(タグ間)
git
svn
クローン
git*
git
ログ (50件)
git
svn
ログ (全て)
git
svn
ログ (ファイル)
git
svn
更新
git
svn
Blame
git
svn
サイズ
git
svn

テストのために、大規模なAWSインスタンスが同じアベイラビリティゾーンに設定されました。GitとSVNが両方のマシンにインストールされ、RubyのリポジトリがGitとSVNの両方のサーバーにコピーされ、両方で一般的な操作が実行されました。

いくつかのケースでは、コマンドは完全に一致しません。ここでは、最小公倍数で一致させようと試みました。例えば、「コミット」のテストにはGitのプッシュ時間も含まれています。これは、SVNでは2つのコマンドを分離できないのに対し、ほとんどの場合、コミット直後に実際にサーバーにプッシュすることはないためです。

これらの時間はすべて秒単位です。

操作 Git SVN
ファイルのコミット (A)変更された113ファイル(2164行追加、2259行削除)を追加、コミット、プッシュ0.642.604倍
画像のコミット (B)1kBの画像を1000個追加、コミット、プッシュ1.5324.7016倍
現在の差分変更された187ファイル(1664行追加、4859行削除)と直前のコミットとの差分0.251.094倍
過去の差分4つ前のコミットとの差分(269ファイル変更/3609行追加、6898行削除)0.253.9916倍
差分(タグ間)2つのタグ間の差分(v1.9.1.0/v1.9.3.0)1.1783.5771倍
ログ (50件)直近50件のコミットログ(19kBの出力)0.010.3831倍
ログ (全て)全コミットのログ(26,056コミット – 9.4MBの出力)0.52169.20325倍
ログ (ファイル)単一ファイルの履歴ログ(array.c – 483リビジョン)0.6082.84138倍
更新コミットAのシナリオでのプル(113ファイル変更、2164行追加、2259行削除)0.902.823倍
Blame単一ファイル(array.c)の行ごとの注釈1.913.041倍

これはSVNにとって最良のシナリオであることに注意してください。つまり、負荷のないサーバーがクライアントマシンとギガビット接続されている状態です。この接続が遅い場合、SVNのこれらの時間のほとんどはさらに悪化しますが、Gitの時間の多くは影響を受けません。

明らかに、これらの一般的なバージョン管理操作の多くにおいて、GitはSVNにとって理想的な条件下でさえ、SVNよりも1桁から2桁高速です

Gitが遅くなる一つの点は、最初のクローン操作です。このとき、Gitは最新バージョンだけでなく、全履歴をダウンロードします。上の図でわかるように、一度しか実行されない操作としては、それほど遅いわけではありません。

操作 Git* Git SVN
クローンGitのクローンとシャロークローン(*) vs SVNのチェックアウト21.0107.514.0
サイズ (MB)クローン/チェックアウト後のクライアント側の全データとファイルのサイズ (MB)181.0132.0

Gitがプロジェクトの全履歴にわたるすべてのファイルの各バージョンを保持しているにもかかわらず、クライアント側のデータサイズが非常に似ていることも興味深い点です。これは、Gitがクライアント側でデータをいかに効率的に圧縮・保存しているかを示しています。

scroll-to-top