Par Anonyme (non vérifié) , 29 avril 2026

Vocabulaire de performance

"Performance à l'échelle" peut signifier beaucoup de choses : temps de clone, vitesse de log/blame, throughput de commits.

Clone et fetch

Les pack files de Git utilisent agressivement la compression delta. Mercurial utilise des bundle files avec une compression similaire.

Opérations locales

Les deux systèmes effectuent les opérations locales entièrement depuis le disque. Le cœur Python pur de Mercurial était historiquement plus lent.

time git log --oneline | wc -l       # ~5-10 secondes
time hg log --template '{rev}\n' | wc -l  # ~10-20 secondes

Taille de l'arbre de travail

Les deux font des mises à jour d'arbre de fichiers en parcourant les trees.

Utilisation mémoire

Le runtime Python de Mercurial impose un plancher mémoire plus élevé que le cœur C de Git.

Stockage de dépôt

Les deux utilisent le stockage adressé par contenu avec compression delta.

Opérations concurrentes

L'index Git utilise des locks de fichiers. Mercurial utilise un locking similaire.

Scaling côté serveur

Les serveurs Git hébergent régulièrement des dépôts avec des centaines de milliers de contributeurs.

Échelle monorepo

Microsoft (Windows in Git via VFS for Git / Scalar) et Meta (Sapling) ont fait face au même problème.

# Git avec sparse checkout et 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 avec sparse et narrow
hg clone --narrow --include 'apps/myapp' --include 'shared/utils' \
  https://example.com/monorepo

Sapling et Scalar

Sapling de Meta est essentiellement "Mercurial réimaginé pour les monorepos".

La conclusion pragmatique

À l'échelle ordinaire, la performance n'est pas un facteur décisif.