Git 2.55.0 ARM64: Cloning Jinja and measuring status
In this article
Cloning pallets/jinja with the native ARM64 build of Git 2.55.0 took 3.25 seconds, and git status stayed between 0.07 and 0.13 seconds.
At this repository size, I did not get the feeling that Windows Git was slow enough to be a problem. It was quite ordinary, despite how much I had braced for the opposite.
According to count-objects -vH, the clone contained 16,658 in-pack objects immediately afterward, one pack, and a size-pack of 7.20 MiB. In other words, this was a 16,658-object, 7.20 MiB repository where status took 70–130 ms. It is not a bad small practical repository to use as a test subject.
The lack of a dramatic improvement after git gc was different from what I expected. Immediately after cloning, status was 0.13 / 0.13 / 0.07 seconds; after gc it was 0.09 / 0.07 / 0.08 seconds. Looking only at the median, it shrank from 0.13 to 0.08 seconds. However, the startup time for the previously measured git --version was 0.0589–0.1069 seconds, so process startup contributes substantially here. I did not have enough evidence to say that only index traversal became faster.
The measurement date was July 8, 2026. My environment was a Surface Pro 11th Edition with a Snapdragon X 12-core X1E80100, Windows 11 Pro 10.0.26200 ARM64, 32GB of memory, and Git 2.55.0. The machine was connected to AC power, with the default Balanced power plan unchanged.
Run clone, then the commands in sequence
The procedure was simple: clone pallets/jinja from GitHub, then measure status, log --oneline -n 1000, count-objects -vH, and gc in that working tree. The clone destination was a temporary work folder separate from repositories I use normally.
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
I also measured git status in arm64-lab and ai-tool-hikaku, two repositories I touch regularly. I wanted to see how much a clean, newly cloned working tree differed from an ordinary working tree. I also expected status to become slower when the working tree was dirty.
This method had an obvious weakness from the start. Even with only three repetitions, measurements around 0.1 seconds include the entire time to start the Git process. If status takes 0.07 seconds, most of that may be git.exe startup, with the actual working-tree check taking much less. I did not separate those parts, which is the weak point of this article.
Read status with startup time included
I am leaving all recorded values here rather than only the medians. The unit remains seconds, as stored in the JSON.
| Operation | All runs_s |
How to read it |
|---|---|---|
| clone | 3.25 | Entire pallets/jinja clone |
| status | 0.13 / 0.13 / 0.07 | git status immediately after clone |
| 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 status after git gc |
| local_status_arm64-lab | 0.09 / 0.10 / 0.07 | This site's working tree |
| local_status_ai-tool-hikaku | 0.07 / 0.08 / 0.08 | Another everyday repository |
I was also surprised that log --oneline -n 1000 took 0.09–0.12 seconds. I expected reading 1,000 history entries to be clearly heavier than status, but the values are in almost the same range. Again, there is a startup-time floor, so 0.09 seconds should not be read as the speed of log processing alone. I only noticed that after measuring.
The count-objects output was: count 0, size 0 bytes, in-pack 16658, packs 1, size-pack 7.20 MiB, prune-packable 0, garbage 0, and size-garbage 0 bytes. Because this was immediately after cloning, there were no loose objects and everything was in one pack.
That also suggests that gc did not have a large amount of work left to do.
Did gc make it faster?
What I most wanted to see was how much status changed before and after git gc. It looked slightly faster. Immediately after cloning it was 0.13 / 0.13 / 0.07 seconds; after gc it was 0.09 / 0.07 / 0.08 seconds. Comparing medians gives 0.13 versus 0.08 seconds, a 50 ms reduction.
It would be risky to call that an effect of gc. There were only three runs, and 0.07 seconds appears both before and after. Git startup time also varies across roughly 0.06–0.11 seconds, so the status values are strongly pulled by startup variation. I should have removed the startup-time floor first. Contrary to my expectation, the clean before/after comparison fell apart.
Before measuring, I thought that reorganizing the pack might make status visibly faster. In reality, the repository already appeared close to compact immediately after cloning. This was not exactly a failure, but the expected difference could not be isolated, so I would redesign the measurement.
Difference from everyday working trees
I measured status in my own repositories too: arm64-lab was 0.09 / 0.10 / 0.07 seconds, and ai-tool-hikaku was 0.07 / 0.08 / 0.08 seconds. Compared with a fresh pallets/jinja clone, the difference was quite small.
I had also been making a slight assumption here. I expected a dirtier working tree to make status slower, but these data show no difference. At least for these two repositories, I could not conclude that normal daily use makes status slower. I would need to separate file count, ignored files, whether the repository is under OneDrive, and the amount of untracked data to see the cause.
The closest description of my experience is that there was no noticeable difference. status did not feel like it was making me wait, and log returned quickly. Windows Git is often described as slow, so I was prepared for trouble, but a 16,658-object, 7.20 MiB repository was perfectly manageable on ARM64 Windows. I do not intend to generalize from this size alone.
What I would measure next
This measurement was enough to see that Git 2.55.0 ARM64 runs and does not get in the way in ordinary use. It was not enough to explain the underlying performance. Around 0.1 seconds, the process startup floor hides the actual status work, and three repetitions are insufficient.
Next time, I would look for a way to invoke Git repeatedly within the same process, or at least measure around 30 times to expose outliers. I would also need separate cases with more untracked files, OneDrive synchronization in progress, and a larger monorepo. There should be variation that is invisible at this size.
Even so, the outcome remains the same. On July 8, 2026, I cloned pallets/jinja with native ARM64 Git 2.55.0 and ran status, log, count-objects, and gc normally. I understand the context behind saying that Windows Git is slow, but at this repository size it was not a practical problem by feel.