Vocabolario di performance

"Performance su scala" puo significare molte cose: tempo di clone/fetch, velocita log/blame, throughput commit, gestione dimensione working tree.

Clone e fetch

I pack file di Git usano compressione delta aggressiva. Mercurial usa file bundle con compressione simile.

Operazioni locali

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

Dimensione working tree

Entrambi i sistemi fanno aggiornamenti del file-tree camminando i tree.

Uso memoria

Il runtime Python di Mercurial impone un floor di memoria piu alto.

Storage repository

Entrambi usano storage content-addressed con compressione delta.

Operazioni concorrenti

L'index di Git usa lock di file.

Scaling lato server

I server Git (GitHub, GitLab, Gitea) ospitano routinamente repository con centinaia di migliaia di contributori.

Scala monorepo

Microsoft (Windows in Git via VFS for Git / Scalar) e Meta (Sapling) hanno affrontato lo stesso problema.

# 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 e Scalar

Sapling di Meta e essenzialmente "Mercurial reimmaginato per i monorepo".

La conclusione pragmatica

A scala ordinaria, la performance non e un fattore decisivo.