Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

go/types, x/tools/go/types/objectpath: frequent use of scope.Names burns significant cycles #51017

Open
amscanne opened this issue Feb 4, 2022 · 4 comments
Labels
NeedsInvestigation Performance
Milestone

Comments

@amscanne
Copy link

@amscanne amscanne commented Feb 4, 2022

What version of Go are you using (go version)?

go1.18-pre10

Does this issue reproduce with the latest release?

Yes.

What operating system and processor architecture are you using (go env)?

Linux, amd64. Not dependent on OS or architecture, however.

What did you do?

The objectpath.For method relies on frequent calls to scope.Names(), which always performs a sort of all names. For large-scale analysis trees, this can consume a significant portion of cycles (30-50% in my case) and can easily be memoized. This can either be done by objectpath as a consumer of the API, or within the *types.Scope object.

What did you expect to see?

Fewer cycles spent sorting.

What did you see instead?

Lots of cycles spent sorting.

@gopherbot
Copy link

@gopherbot gopherbot commented Feb 4, 2022

Change https://golang.org/cl/383075 mentions this issue: go/types: memoize scope.Names() result

@findleyr
Copy link
Contributor

@findleyr findleyr commented Feb 4, 2022

Thanks for filing.

Need to think about this. I'll just note that in the profile linked on that CL, there is also significant amount of time spent in Scope.Lookup. But objectpath just needs to walk all the objects, and doesn't care about sorting. I wonder if we should be considering an entirely new Scope API... Or maybe that is further evidence that it would be better for us to build a layer in objectpath that can significantly optimize the calculation of paths. Compare x/tools/go/ast/inspector.

@cherrymui cherrymui added Performance NeedsInvestigation labels Feb 8, 2022
@cherrymui cherrymui added this to the Backlog milestone Feb 8, 2022
@gopherbot
Copy link

@gopherbot gopherbot commented May 6, 2022

Change https://go.dev/cl/404514 mentions this issue: go/types/objectpath: implement fast path for concrete methods

@gopherbot
Copy link

@gopherbot gopherbot commented May 10, 2022

Change https://go.dev/cl/405354 mentions this issue: go/types/objectpath: cache repeated queries (WiP)

gopherbot pushed a commit to golang/tools that referenced this issue May 13, 2022
Don't search for a matching method on all types in the package scope
when we can trivially determine the type's name. This avoids both a
linear search over the scope, as well as the currently rather costly
call to scope.Names itself.

Updates golang/go#51017

Change-Id: I614f4b1b149d6b42728d3f22f5e47e8ff87a5392
Reviewed-on: https://go-review.googlesource.com/c/tools/+/404514
Run-TryBot: Alan Donovan <adonovan@google.com>
gopls-CI: kokoro <noreply+kokoro@google.com>
Run-TryBot: Dominik Honnef <dominik@honnef.co>
Reviewed-by: Alan Donovan <adonovan@google.com>
Reviewed-by: Robert Findley <rfindley@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
NeedsInvestigation Performance
Projects
None yet
Development

No branches or pull requests

4 participants