Possible performance regression in for-each-ref in git 2.40.0

Andrzej Dębski· Jun 25, 2025, 11:28 UTC · lore

One of Dropbox SWEs observed that a specific git command in Go language tooling https://github.com/golang/go/blob/e515ef8bc271f632bb2ebb94e8e700ab67274268/src/cmd/go/internal/modfetch/codehost/git.go#L758 took over 20 seconds. Internally we distribute git 2.46.0 right now but the SWE had an older version of git around (2.39.5) and observed a performance regression between those 2 versions.

We've did some performance measurements and the command like "git for-each-ref --format="%(refname)" refs/tags --merged HEAD > /dev/null" spent majority of time in function "tips_reachable_from_bases" introduced in git 2.40.0: https://github.com/git/git/commit/cbfe360b140fe92d9c4a763bf630c3b8ba431522

Similar performance degradation can be observed in git 2.50

Given that the command references tags I've experimented and observed that the command execution time decreased with the amount of tags I've removed from the local copy of the repo.

Context: in Dropbox we operate a large monorepo with around 65K tags
right now and growing every day.

The question is, given the same command used to be much faster in older versions of git is this considered a regression and can be fixed in future releases of git?

[System Info]
git version: 2.46.0
cpu: bazel
built from commit: bazel
sizeof-long: 8
sizeof-size_t: 8
shell-path: /bin/sh
libcurl: 7.82.0
OpenSSL: OpenSSL 1.1.1w  11 Sep 2023
zlib: 1.2.13
uname: Linux 6.8.0-1029-aws #31~22.04.1-Ubuntu SMP Thu Apr 24 21:16:18
UTC 2025 x86_64
compiler info: gnuc: 11.2
libc info: glibc: 2.35
$SHELL (typically, interactive shell): /bin/bash

Kristoffer Haugsbakk· Jun 25, 2025, 13:17 UTC · re: Andrzej Dębski · lore

Re: Possible performance regression in for-each-ref in git 2.40.0

On Wed, Jun 25, 2025, at 13:28, Andrzej Dębski wrote:

Show 43 quoted lines

> One of Dropbox SWEs observed that a specific git command in Go
> language tooling
> https://github.com/golang/go/blob/e515ef8bc271f632bb2ebb94e8e700ab67274268/src/cmd/go/internal/modfetch/codehost/git.go#L758
> took over 20 seconds. Internally we distribute git 2.46.0 right now
> but the SWE had an older version of git around (2.39.5) and observed a
> performance regression between those 2 versions.
>
> We've did some performance measurements and the command like "git
> for-each-ref --format="%(refname)" refs/tags --merged HEAD >
> /dev/null"
> spent majority of time in function "tips_reachable_from_bases"
> introduced in git 2.40.0:
> https://github.com/git/git/commit/cbfe360b140fe92d9c4a763bf630c3b8ba431522
>
> Similar performance degradation can be observed in git 2.50
>
> Given that the command references tags I've experimented and observed
> that the command execution time decreased with the amount of tags I've
> removed from the local copy of the repo.
>
> Context: in Dropbox we operate a large monorepo with around 65K tags
> right now and growing every day.
>
> The question is, given the same command used to be much faster in
> older versions of git is this considered a regression and can be fixed
> in future releases of git?
>
>
> [System Info]
> git version: 2.46.0
> cpu: bazel
> built from commit: bazel
> sizeof-long: 8
> sizeof-size_t: 8
> shell-path: /bin/sh
> libcurl: 7.82.0
> OpenSSL: OpenSSL 1.1.1w  11 Sep 2023
> zlib: 1.2.13
> uname: Linux 6.8.0-1029-aws #31~22.04.1-Ubuntu SMP Thu Apr 24 21:16:18
> UTC 2025 x86_64
> compiler info: gnuc: 11.2
> libc info: glibc: 2.35
> $SHELL (typically, interactive shell): /bin/bash

+CC author.

-- 
Kristoffer Haugsbakk