Microsoft は、Windows のソースである膨大なコード コレクションを管理するために Git を採用し、その過程で修正する必要があったパフォーマンスの問題を共有してきました。
マイクロソフトが「地球上で最大の Git リポジトリ」と呼ぶものの現状報告は、計画されている移行の基盤として「ファット Git リポジトリ」ハンドラーである Git 仮想ファイル システムのリリースに続くものです。
レドモンドは、この移行に満足しているようだ。特に、2,000 人規模の Windows OneCore チーム全体を、週末の間に Source Depot 内部ツールから Git に移行できたことに、満足しているようだ。
Redmondista の Brian Harry 氏は、300 GB の Windows リポジトリが現在 1 日あたり 8,421 件のプル リクエストと 1,760 件の公式ビルドを処理しているとブログに投稿しました。
それでも、社内調査に回答した 251 人のスタッフのうち 28 パーセント以上が満足しておらず、その理由を理解することは、スケーラビリティの数字を振り回すのと同じくらい移行をスムーズに進めるために重要だと彼は指摘します。
ハリス氏が報告した理由には、ツールが Git をサポートしていないこと、新しいプロセスを学習する必要があること、パフォーマンスが需要を満たしていないことなどが含まれています。
彼によれば、パフォーマンスは主に Microsoft の Git 仮想ファイル システムによるもので、これは Git をユーザーに対して「通常の」ファイル システムとして提示するように設計されたレイヤーです。
Microsoft は、GVFS を使用して約 3,500 人のエンジニアのテレメトリを取得しました (以下を参照) (「P80」は、過去 7 日間のユーザーの 80 パーセンタイルの結果を示しています。赤は週の初めと終わりの変化を示しています)。
GVFS は「バニラ Git」よりも高速ですが、システムは時間の経過とともに遅くなっています (リポジトリとユーザー数が増加するため)。
「エンジニアは時間の経過とともにコードベースをくまなく調べ、より多くのものに触れるようになります。その結果、ある時点で触れたものの、実際にはもう使われておらず、ましてや一度も変更されていないファイルが大量に残ります。これが徐々にパフォーマンスの低下につながります。」
同氏は、Git と比較して、GVFS では「多くの操作がリポジトリ内のファイル数に比例するものから、読み取られたファイル数に比例するものに変わる」と指摘しています。
これが速度低下の原因なので、レドモンドは「O(modified)」と呼ぶもので GVFS を改良しています。これは、読み取られたファイルの数ではなく、ユーザーが現在コミットしていない編集を行っているファイルの数に比例するキー コマンドです。
彼は 4 つのコマンドに対して O(modified) を測定し、Status では 2.3 倍、Add では 3.5 倍、Commit では 6.2 倍、Checkout では 29 倍の速度向上が得られたと主張しています。
もう一つの「もっと努力すべき点」は、リモートオフィスにあることが判明しました。GVFSの現在のイテレーションは過度に集中化されているため、レドモンドではわずか127秒で完了するCloneのような操作が、マイクロソフトのノースカロライナオフィスでは25分近くもかかっています。
それを回避するために、ハリーは、GVFS のメンテナーがプロキシ機能を追加したと書いています。「プロキシを構成して最新の状態にしておくと、70 秒かかりました (レドモンドのチームはプロキシを使用しておらず、インターネット経由で何百マイルも離れた Azure データ センターに移動する必要があるため、レドモンドよりも高速です)。」
サードパーティも GVFS に満足しているようで、SourceTree、Tower、Visual Studio、Git for Windows での Atlassian のサポートも受けています。®
