Von Gast (nicht überprüft) , 29 April 2026

Performance-Vokabular

"Performance im Massstab" kann viele Dinge bedeuten.

Klon und Fetch

Git's Pack-Files verwenden aggressive Delta-Kompression. Mercurial verwendet Bundle-Files mit ahnlicher Kompression.

Lokale Operationen

# Benchmark: log on a million-commit repo
time git log --oneline | wc -l
time hg log --template '{rev}\n' | wc -l

Working-Tree-Grosse

Beide Systeme machen Datei-Tree-Updates durch Tree-Walking.

Speicherverbrauch

Mercurials Python-Runtime erzwingt einen hoheren Speicher-Floor.

Repository-Storage

Beide verwenden content-addressed Storage mit Delta-Kompression.

Parallele Operationen

Git's Index verwendet File-Locks.

Server-seitige Skalierung

Git-Server (GitHub, GitLab, Gitea) hosten routinemassig Repositories mit Hunderttausenden von Mitwirkenden.

Monorepo-Massstab

Microsoft (Windows in Git via VFS for Git / Scalar) und Meta (Sapling) standen vor demselben Problem.

# Git with sparse checkout and partial clone
git clone --filter=blob:none --sparse https://example.com/monorepo.git
cd monorepo
git sparse-checkout init --cone
git sparse-checkout set apps/myapp shared/utils

# Mercurial with sparse and narrow
hg clone --narrow --include 'apps/myapp' --include 'shared/utils' \
  https://example.com/monorepo

Sapling und Scalar

Sapling von Meta ist im Wesentlichen "Mercurial neu gedacht fur Monorepos".

Die pragmatische Schlussfolgerung

Bei gewohnlichem Massstab ist Performance kein entscheidender Faktor.