x/tools/gopls: add ability to avoid scanning an entire workspace #53278
What did you do?
We've recently made an attempt to add
What did you expect to see?
No performance/behavior degradation, only behavior ones (like fetching 3rd party modules via
What did you see instead?
Based on experiments it looks like before adding
While I understand that it potentially was not an intended gopls behavior, but are you open to return it via an additional opt-in option? Without that gopls in current state is not usable on a repository of the given size.
Note, I've also tried to set
Editor and settings
The text was updated successfully, but these errors were encountered:
Regarding didChange processing time, we're working on landing the stack in #45686 now (for the next release). This should help significantly, though there will still be a fair bit of time spent "inheriting", and unfortunately that cant be avoided without more significant changes to gopls' caching logic. We are going to make those changes, but it will take longer.
Assuming you've narrowed your workspace in the go.work, the real problem is that gopls is walking files unnecessary, and that's just a bug. We have a couple open issues related to this also in the v0.9.0 milestone.
Would you be willing to try out some experimental patches in your workspace?
Hi, yeah, I can try them out.
I've also made some experiments myself, one thing I've noticed is that a huge chunk of time is spent in copying
@euroelessar before you spend time cleaning it up, you can share what you have and we can confirm that it meets requirements. There are some non-obvious reasons why we use a reference counted cache, for example sharing results across multiple views / sessions. But there are of course other ways to achieve this.
@findleyr does it satisfy the requirements, should I continue investment in the change & make it satisfy the code quality requirements? (like add documentation, fix code style, add typing, etc)
based on my experiments the combination of this change (extended to