テストリポジトリ
400万件のコミット、線形履歴、約130万件のファイル。 .gitフォルダーのサイズは約15 GBで、repackコマンドで圧縮されています。
git repack -a -d -f --max-pack-size=10g --depth=100 --window=250
このプロセスは、優れたマシン（大量のメモリ、SSD）で約2日かかりました。 インデックスファイルのサイズは191 MBでした。
このようなリポジトリーでのGitの速度は、まったく楽しいものではありません。 通常のHDDと10 GBを超えるRAMを搭載したサーバーでコマンドを実行した結果（コマンドは数回繰り返され、「ホット」OSキャッシュを使用した場合よりも高速に動作します）：
git status
コールドキャッシュで39分、ホットキャッシュで24秒。
git blame
44分11分。
git add
（ファイルの最後に数文字を追加して追加）
7秒と5秒。
git commit -m "foo bar3" --no-verify --untracked-files=no –quiet --no-status
41分20秒。
Facebookの開発者は、このような結果は自分に合わないと言い、状況を修正する方法についてアドバイスを求めます。 おそらく、Gitでは、特殊な個別のサーバーを割り当て、ファイルシステムレベルでそれをサポートして、個々の操作を高速化する必要があります（たとえば、どのファイルが変更されたかを判断します）。 個々のサーバーをサポートするためにGitコードを書き直すか、一種のアクセスインターフェイスとしてスクリプトを使用してアドインを作成する必要があります。
Redstoneの同僚は 、パフォーマンスの低下はGitの多数のO（n）構造によるものであり、大きなサイズで問題が発生すると説明しました。 インデックスファイル自体は、わずかな変更でも完全にゼロから書き換えられ、大規模なプロジェクトではサイズが100 MBを超えます。 さらに、Gitは
lstat
を使用してファイルの変更をチェックするため、特にコールドキャッシュでは、何百万ものファイルにディスクブレーキがかかります。
一般的に、Facebookの開発者は、パフォーマンスを改善するためにGitを書き直した方が良いと示唆しています。 リポジトリをいくつかの部分に分割することを拒否します。