Git 2.55.0 ARM64 で Jinja を clone して status を測った
Git 2.55.0 の ARM64 ネイティブ版で pallets/jinja を clone したら3.25秒、git status は0.07〜0.13秒に収まった。
この規模のリポジトリでは、Windows の Git が遅くて困る、という感覚にはならなかった（身構えていたわりに、かなり普通だった）。
count-objects -vH で見ると、clone 直後の中身は in-pack が16658オブジェクト、pack は1本、size-pack は7.20 MiB。つまり、16658オブジェクト・7.20 MiB のリポジトリで status が70〜130msだった、という読み方になる（小さめの実用リポジトリとしては悪くない題材）。
git gc のあとに劇的な改善が出なかったのは、予想と違ったところだ。clone 直後の status は0.13 / 0.13 / 0.07秒で、gc 後は0.09 / 0.07 / 0.08秒。中央値だけ見れば0.13秒から0.08秒に縮んでいる。ただ、前に測った git --version の起動時間が0.0589〜0.1069秒だったので、ここにはプロセス起動時間がかなり乗っている。インデックス走査だけが速くなったと言い切るには材料が薄い。
測定日は2026-07-08。私の環境では Surface Pro 11th Edition、Snapdragon X 12-core X1E80100、Windows 11 Pro 10.0.26200 ARM64、メモリ32GB、Git 2.55.0 という組み合わせで試した。電源は AC 接続、電源プランは既定のバランスのままにしている。
clone してから順に叩く
やったことは単純で、GitHub から pallets/jinja を clone し、その作業ツリーで status、log --oneline -n 1000、count-objects -vH、gc を順番に測った。clone 先は一時的な作業フォルダで、普段触っているリポジトリとは別の場所にしている。
git clone --quiet https://github.com/pallets/jinja.git <clone-dir>
git -C <clone-dir> status --short
git -C <clone-dir> log --oneline -n 1000
git -C <clone-dir> count-objects -vH
git -C <clone-dir> gc
合わせて、自分が日常的に触っている arm64-lab と ai-tool-hikaku でも git status を測ってみた。clone したてのきれいな作業ツリーと、普段の作業ツリーでどれくらい違うかを見たかったからだ。作業ツリーが汚れていると status は遅くなるはず、という予想もあった。
ただし、この測り方には最初から弱点がある。反復も3回だけにしたところで、しかも0.1秒前後の測定なので、Git のプロセスを起動する時間が丸ごと入ってしまう。status が0.07秒だったとしても、その大半が git.exe の起動で、実際の作業ツリー確認はもっと短い可能性が高い（ここを分けられていないのが、この記事の弱いところ）。
status は起動時間込みで見る
中央値だけではなく、取れた値を全部置いておく。単位は JSON に入っていた秒のままだ。
| 操作 | 全 runs_s | 読み方 |
|---|---|---|
| clone | 3.25 | pallets/jinja の clone 全体 |
| status | 0.13 / 0.13 / 0.07 | clone 直後の git status |
| log1000 | 0.12 / 0.09 / 0.11 | git log --oneline -n 1000 |
| count_objects | 0.10 / 0.06 / 0.18 | git count-objects -vH |
| gc | 0.69 | git gc |
| status_after_gc | 0.09 / 0.07 / 0.08 | git gc 後の git status |
| local_status_arm64-lab | 0.09 / 0.10 / 0.07 | このサイトの作業ツリー |
| local_status_ai-tool-hikaku | 0.07 / 0.08 / 0.08 | 別の普段用リポジトリ |
log --oneline -n 1000 が0.09〜0.12秒なのも手元では意外だった。1000件の履歴を読むので status より明確に重いかと思っていたが、数字だけ見るとほぼ同じ帯にいる。とはいえ、ここでも起動時間の床があり、0.09秒という値は、ログ処理だけの速さとは別の読み方になる（このあたりは測定してから気づいた）。
count-objects の出力は、count が0、size が0 bytes、in-pack が16658、packs が1、size-pack が7.20 MiB、prune-packable が0、garbage が0、size-garbage が0 bytesだった。clone 直後なので loose object がなく、1本の pack にまとまっている。
だから gc に大きな仕事が残っていなかった、という見方もできそうな話。
gc で速くなったのか
一番見たかったのは、git gc の前後で status がどれくらい変わるかだった。結果は少しだけ速く見える。clone 直後は0.13 / 0.13 / 0.07秒、gc 後は0.09 / 0.07 / 0.08秒。中央値で並べるなら0.13秒から0.08秒なので、50msぶん縮んだことになる。
ただ、これを gc の効果と断定するのは危うい。3回しか測っていないし、0.07秒という値が前後どちらにも出ている。さらに Git の起動時間が約0.06〜0.11秒の幅を持っているので、status の測定値そのものが起動時間の揺れにかなり引っ張られる。なぜ先に起動時間の床を引かなかったのか。ここは予想と違って、きれいな before / after は崩れてしまった。
測る前は、pack が整理されて status が目に見えて速くなるかもしれないと考えていた。実際には、clone 直後から already compact に近い状態に見える。失敗というほどではないが、期待した差を取り出せなかった点では、測定設計をやり直したくなる結果だ。
普段の作業ツリーとの差
自分のリポジトリでも status を測った。arm64-lab は0.09 / 0.10 / 0.07秒、ai-tool-hikaku は0.07 / 0.08 / 0.08秒。clone したての pallets/jinja と比べても、差はかなり薄い。
ここも少し勘違いしていた。作業ツリーが汚れているほど status は遅くなるはず、という前提で見ていたが、このデータだけでは差が出ていない。少なくとも手元の2本では、日常的に触っているから遅い、という結論には届かずに終わった。ファイル数、ignore されるファイル、OneDrive 配下かどうか、未追跡ファイルの量などを分けて測らないと、原因は見えにくい。
体感差はない、というのが今回の実感に近い。status を打って待たされる感じはなく、log もすぐ返る。Windows の Git は遅いという話をよく見るので身構えていたが、少なくとも16658オブジェクト・7.20 MiBくらいのリポジトリでは、ARM64 Windows でも普通に扱えた（このサイズだけで一般化するつもりはない）。
次に測るなら
今回の測定は、Git 2.55.0 ARM64 が動くか、普段使いで引っかかるかを見るには十分だった。一方で、性能の中身を説明するには足りない。0.1秒前後の世界では、プロセス起動時間を引かないと status の本体が隠れる。反復3回も不足している。
次にやるなら、同じプロセス内で複数回 Git を呼べる方法を探すか、少なくとも30回くらい測って外れ値を見たい。未追跡ファイルを増やしたケース、OneDrive 同期中のケース、もっと大きな monorepo も別に必要になる（このサイズだけでは見えない揺れがあるはずだ）。
それでも、今回の着地は変わらない。2026年7月8日の手元では、Git 2.55.0 の ARM64 ネイティブ版で pallets/jinja を clone し、status、log、count-objects、gc まで普通に動いた。Windows の Git が遅いと言われる文脈は理解しつつ、このサイズのリポジトリでは体感で困らずに済んでいる。