resolver: log per-sub-pass timing for the attribution sweep#268
Merged
Conversation
runFileAttributionPassesLocked ran six binding passes (rebindGoMethodReceivers, bindBareNameScopeRefs, bindDataflowCalleeRefs, bindGenericParamRefs, attributeGoBuiltins, attributeGoExternalCalls) as one opaque duration in the existing "resolver: pass complete" log line. Break it out per sub-pass, matching the framework-synthesizer timing added earlier, so a future single-pass regression here has a breadcrumb instead of hiding behind one aggregate number. Measured on a 26-repo real-store snapshot: no sub-pass dominates (9-15s each of ~66s combined) and none scans the graph unscoped — every pass already uses a kind-scoped EdgesByKind/NodesByKind query, several with comments noting that choice was deliberate. This is logging only; no behavior change.
2 tasks
zzet
added a commit
that referenced
this pull request
Jul 10, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Follow-up to #267's framework-dispatch-synthesis investigation — checked whether
go_attribution(the other large chunk ofresolve_son a real multi-repo cold start, ~66-100s) had the same class of bug (an unscopedAllEdges()/AllNodes()scan instead of a kind-scoped query).It doesn't. Instrumented all 6 attribution sub-passes and measured against a snapshot of a real 26-repo store: no sub-pass dominates (9-15s each), and every one already uses
EdgesByKind/NodesByKind(SQL-side kind filter), several with comments noting that choice was deliberate.This PR is logging only: per-sub-pass timing on the existing
resolver: pass completeline, so a future regression here has a breadcrumb instead of hiding behind one aggregate duration (the same value framework-dispatch-synthesis's timing already provides).Follow-up investigation (lang_dispatch_reconcile's own sub-passes, plus a real finding and a reverted regression in
EdgesWithUnresolvedTarget) continues in #269.Test plan
GOWORK=off go build ./...GOWORK=off go test -race ./internal/resolver/... ./internal/indexer/...