Does this issue reproduce with the latest release?
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.
The text was updated successfully, but these errors were encountered:
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.
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.
Run-TryBot: Alan Donovan <firstname.lastname@example.org>
gopls-CI: kokoro <email@example.com>
Run-TryBot: Dominik Honnef <firstname.lastname@example.org>
Reviewed-by: Alan Donovan <email@example.com>
Reviewed-by: Robert Findley <firstname.lastname@example.org>
TryBot-Result: Gopher Robot <email@example.com>