Does automatic garbage collection impact performance in large repositories?

Short answer

Yes—automatic garbage collection can cause noticeable, unpredictable latency in large repositories, and it is a common cause of UI freezes in Git GUI clients like Tower. The overhead is negligible in small repositories, but when the object count grows large, the packing phase of git gc is CPU- and I/O-intensive, and if it fires during a fetch or commit, you feel it as a stall. The practical recommendation for high-volume repositories is to keep automatic GC conservative and run compaction manually during off-peak hours.

What is confirmed vs. likely

Confirmed Git behavior: Git triggers automatic GC when loose-object and packfile thresholds are exceeded (controlled by gc.auto and related config keys). When it runs, it repacks objects into packfiles and prunes unreachable data. On a repository with hundreds of thousands of objects, this can take seconds to minutes and saturate disk I/O.

Likely explanation for your symptom: Tower shells out to Git for most operations, so an auto-GC triggered mid-fetch or mid-commit blocks the underlying Git process, which surfaces as a frozen or sluggish UI. The dips feel random because the trigger is threshold-based, not scheduled.

Uncertainty: I cannot verify whether your Tower version exposes a built-in GC scheduler. Tower has historically delegated maintenance to Git itself rather than offering a cron-like scheduling UI. Check Tower's preferences and release notes for your version, or confirm with their support. The workaround below does not depend on any Tower-specific feature.

Recommended approach

1. Check whether auto GC is active: inspect the repository config.

git config --get gc.auto
git count-objects -v

If gc.auto is unset, Git's default threshold applies. The count-objects -v output shows loose object and pack counts—high loose-object counts mean auto GC will fire soon.

1. Raise or disable the auto threshold for this repository so GC stops firing during work hours:

# Option A: raise the loose-object threshold (conservative)
git config gc.auto 10000

# Option B: disable auto GC entirely for this repo
git config gc.auto 0

Option B is reasonable only if you commit to running maintenance yourself—an unmaintained repository degrades over time.

1. Schedule manual compaction off-peak. Run a scoped, non-aggressive GC nightly or weekly via cron, launchd, or Task Scheduler:

git -C /path/to/repo gc --auto   # no-op unless thresholds are met
# or a full pass during a quiet window:
git -C /path/to/repo gc

Avoid git gc --aggressive as a routine step; it is expensive and rarely worth the cost. Also avoid --prune=now unless you are certain no in-flight work references recent objects.

Verifying the impact

Time a git fetch before and after a manual git gc, and watch CPU/disk in Activity Monitor or Task Manager during the GC run. If fetch times drop and the random stalls disappear after disabling auto GC plus scheduled maintenance, the diagnosis is confirmed.

Caveats

Exact thresholds and Tower's behavior vary by Git and Tower version—verify against your installed versions. If your stalls persist after GC is controlled, the bottleneck may be elsewhere (antivirus scanning of .git, network latency, or large-file handling), which is worth investigating before tuning further.