Hacktoberfest 2026: die Issues, die Maintainer für den Oktober markiert haben – offen und einsteigerfreundlich. Hacktoberfest-Issues durchsuchen

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

Offen
  • Stimmt etwas nicht?
#28,142 1 Kommentar 0 Reaktionen 0 zugewiesene Personen Auf GitHub ansehen

Maintainer antworten meist innerhalb von 1 Tag

Dieses Issue hat noch niemand übernommen.

Bewertung

Schwierigkeit
4/5
Geschätzter Aufwand
3-5 Tage
Anfängerfreundlichkeit
48/100
Issue-Typ
Refactoring
Klarheit
Größtenteils klar
Aktivitätsstatus
Ruhig
Tech-Stack
go
Bereich
backend, performance

Rechercherichtung

Lies coderd/database/db2sdk/db2sdk.go, insbesondere den Konverter für den Chat-Diff-Status und seine Aufrufer Chat, ChildChatRows und ChatRowsWithChildren, und untersuche anschließend die Konstruktion von gitprovider und die URL-Methoden. Vergleiche die beiden vorgeschlagenen Lösungsformen, führe die relevanten Chat-/Datenbanktests und Benchmarks aus, sofern verfügbar, und bestätige, dass die Konvertierung nicht mehr pro Zeile einen Provider konstruiert, während die Repository- und Branch-URLs korrekt bleiben.

Vom Indexierungsmodell aus dem Issue-Text verfasst.

Beschreibung

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.

Vorherrschende Sprache
Go
Sterne
16.6k
Forks
1.6k
Ø Merge
2 T. 4 Std.
Gemergte PRs (30 T.)
501

Entwicklungsumgebung

Erste Schritte

  1. Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
  2. Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
  3. Forken Sie das Repository und arbeiten Sie in einem Branch.
  4. Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.

Mehr aus coder/coder

Alle Issues in coder/coder

Ähnliche Issues

Weitere Issues zu Go

Neue Issues direkt in Ihr Postfach

Eine kurze Übersicht über anfängerfreundliche GitHub-Issues.