Performance data

Homebrew core

926,163 commits, 9,262 tracked files and 15 refs at b61ec9f1460b, with a commit-graph file, recorded 2026-11-07. 30 samples of each command, the app and Git taking turns.

Linux kernel, as cloned

1,505,332 commits, 97,359 tracked files and 955 refs at 05441d697f7f, without a commit-graph file, recorded 2026-11-04. 30 samples of each command, the app and Git taking turns.

Linux kernel, with a commit-graph

1,505,332 commits, 97,359 tracked files and 955 refs at 05441d697f7f, with a commit-graph file, recorded 2026-11-04. 30 samples of each command, the app and Git taking turns.

BranchHelm

8,821 commits, 22,410 tracked files and 24 refs, with a commit-graph file, recorded 2026-11-07. 30 samples of each command, the app and Git taking turns.

A fix these measurements found

To draw one page of history, the app read the trunk's entire first-parent chain to learn which rows were on it. The fix reads only as deep as the page reaches and proves the rest with Git's own reachability check. Two builds of the same base, before and after it, timed back to back in one quiet window on the 926,163-commit repository on 2026-11-04:

On a short trunk one whole read is quicker than several bounded ones, so the app now runs both and takes the first answer. Every sitting above was taken on a build that has the fix.

How it was measured

A commit-graph file is the index Git writes during its routine maintenance; without one Git must read every commit to order the history. A fresh clone has none, so the Linux kernel is timed both ways.

The release build of the app runs headless in a throwaway profile, with Workspace Trust granted to the repository so that each Git read is the one a person would trigger. A script sends each command over the app's local connection and waits for the whole reply. Beside each command, the same script runs the Git reads that command needs, directly, and the two take turns. So the ratio is everything the app does on top of those reads: starting each one, reading its output, any reads of its own and answering in JSON. A row's budget is the largest ratio the harness accepts for it, and a row over it is marked. Where Git itself answers in a few milliseconds, that fixed cost shows as a larger ratio, and history on BranchHelm's own repository is the clearest case: it starts several Git commands in turn, each with a start-up cost of its own.

• History also reads the trunk's first-parent chain to mark which rows are on it; Git alone does not, so those reads count as the app's.
• The app keeps branch counts cached between repeated samples; Git alone has no cache, so that row flatters the app.
• Listing every file also walks for empty folders, which has no Git equivalent and counts as the app's.
• The app returns history in pages of at most 500 commits, so the longest history row asks for one whole page and Git reads the same 500. The app also reads one commit past the page to learn whether another follows, and that read counts as the app's.

A sitting counts only when other processes on the machine used at most 1.5 cores, checked before each timing of a command and its Git reads, from the CPU time each process accumulated. Machine: Apple M5 Pro, 24 GB, macOS on arm64, with Git 2.50.1 (Apple Git-155).

An earlier measurement

Reading the conflict index of a 13,703-file repository, before and after an optimisation, recorded 2026-10-06 on a busier host than the sittings above. Server time only.

Not measured yet

• Time from launch to the first frame.
• Memory and processor use while idle.
• How long the screen takes to paint a reply.
• Any machine but this Mac, including Windows and Linux.

The raw data

Every sample of every sitting, as JSON, including the commands timed without a Git comparison. Paths, build hashes and BranchHelm's own revisions are removed; the public repositories keep theirs. The repository keeps the full records, and each one's SHA-256 is listed in the file.