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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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




[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux