Hacktoberfest 2026 : les issues que les mainteneurs ont marquées pour octobre, ouvertes et accessibles aux débutants. Parcourir les issues Hacktoberfest

perf(coderd/database/db2sdk): avoid constructing a full git provider per chat row

Ouverte
#28,142 1 commentaire 0 réactions 0 personnes assignées Voir sur GitHub

Les mainteneurs répondent en général sous 1 jour

Personne n'a encore pris cette issue.

Évaluation

Difficulté
4/5
Temps estimé
3-5 jours
Accessibilité débutants
48/100
Type d'issue
Refactorisation
Clarté
Plutôt claire
Activité
Calme
Stack technique
go
Domaine
backend, performance

Piste de recherche

Lisez coderd/database/db2sdk/db2sdk.go, en particulier le convertisseur de statut du diff du chat et ses appelants Chat, ChildChatRows et ChatRowsWithChildren, puis examinez la construction de gitprovider et les méthodes d’URL. Comparez les deux formes de correction proposées, exécutez les tests et benchmarks pertinents du chat/de la base de données s’ils sont disponibles, et confirmez que la conversion ne construit plus un provider par ligne, tandis que les URL du dépôt et de la branche restent correctes.

Rédigé par le modèle d'indexation à partir du texte de l'issue.

Description

performance

Follow-up from #27711 (CRF-16).

Problem

coderd/database/db2sdk/db2sdk.go constructs a full GitHub provider per converted chat row to run two pure string functions (ParseRepositoryOrigin and BuildBranchURL).

Measured by four independent reviewers in round 1 of #27711:

  • Construction cost: ~46-73 us, ~46 KB, 451 allocations per call, dominated by three regexp.MustCompile calls in newGitHub plus a fresh 2048-slot cache map.
  • The two string functions actually needed cost ~1.1 us and 195 B. So 97% of the work is thrown away.
  • The construction runs per row via Chat, ChildChatRows and ChatRowsWithChildren (10 call sites), reached from the chat list endpoint. A 100-row list response with branch-but-no-PR rows pays roughly 5 to 7 ms and 4.6 MB of garbage.

Correctness is unaffected: this path only parses and formats URLs, so no ETag state is lost. The code in question:

// coderd/database/db2sdk/db2sdk.go, inside the chat diff status converter
// TODO: This uses the default github.com API base URL,
// so branch URLs for GitHub Enterprise instances will
// be incorrect.
gp, _ := gitprovider.New("github", "", nil)
if gp != nil {
	if owner, repo, _, ok := gp.ParseRepositoryOrigin(status.GitRemoteOrigin); ok {
		branchURL := gp.BuildBranchURL(owner, repo, status.GitBranch)
		...
	}
}

Two fix shapes

  1. Cheap: package-level sync.OnceValue for the default github.com provider.

    • About 5 lines. Kills 97% of the waste for the github.com case, which is the only host this code ever targets today (gitprovider.New("github", "", nil) hardcodes the default base URL).
    • Does not fix the GHE case, but that case is already broken today per the existing TODO.
  2. Proper: move URL parsing and building into package-level functions with package-level regexps, and have the provider methods delegate.

    • About 40 lines, but touches the Provider interface (all implementations).
    • Removes the incentive to construct a provider for string work, not just the cost.
    • Also fixes the existing TODO (GitHub Enterprise hosts get wrong branch URLs) if the functions take the host as a parameter.

The existing TODO above the call already records the correctness half of the same design gap.

Context from #27711

This is the last live instance of the exact class that PR fixed one layer up: per-call provider construction throwing away work and state. Seven reviewers found it independently in round 1, all rated it P4, four with benchmarks that agreed. It predates #27711 and carries no cache state, which is why it stayed out of that PR.

🤖 Generated by Coder Agents on behalf of @johnstcn.

Langage dominant
Go
Étoiles
16.6k
Forks
1.6k
Merge moyen
2 j 1 h
PR mergées (30 j)
485

Préparer son environnement

Par où commencer

  1. Lisez l'issue en entier, puis le guide de contribution du projet.
  2. Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
  3. Forkez le dépôt et travaillez sur une branche.
  4. Ouvrez une pull request qui référence le numéro de l'issue.

Autres issues de coder/coder

Toutes les issues de coder/coder

Issues similaires

Plus d'issues Go

Recevez les nouvelles issues par e-mail

Un résumé court des issues GitHub adaptées aux débutants.