# Possible performance regression in for-each-ref in git 2.40.0 2 messages from 2025-06-25 to 2025-06-25. Participants: Andrzej Dębski, Kristoffer Haugsbakk. Thread: https://gitlist.dev/t/63689 ## Andrzej Dębski, 2025-06-25 11:28 Subject: Possible performance regression in for-each-ref in git 2.40.0 Message-ID: URL: https://gitlist.dev/e/CAHKcSH2_Xse3o5Cq88Fu2s26AAJGNJMGeSvgHAyp-RLruVPnJQ%40mail.gmail.com ``` 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, 2025-06-25 13:17 Subject: Re: Possible performance regression in for-each-ref in git 2.40.0 Message-ID: URL: https://gitlist.dev/e/c0170328-764b-4d31-a66d-5ac56ff87be7%40app.fastmail.com In-Reply-To: ``` On Wed, Jun 25, 2025, at 13:28, Andrzej Dębski wrote: > 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 ```