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

x/tools/cmd/guru: find references results in high CPU on windows visual studio code #30298

MelleKoning opened this issue Feb 18, 2019 · 7 comments


Copy link

@MelleKoning MelleKoning commented Feb 18, 2019

go version go1.11.5 windows/amd64

Does this issue reproduce with the latest release?


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

go env Output
$ go env
set GOARCH=amd64

What did you do?

find all references on a method within Visual Studio Code, this executes guru.exe:

guru -referrers

This issue is also listed here:

Have tried updating guru.exe with the solution described here:
golang/tools#56 (comment)

Did not work. Eventually debugged and guru is parsing an entire tree by calling build.go from guru.go func importQueryPackage; that's where the high CPU load is occurring.

There is some code in build.go source code that uses slashes "/" for pathnames instead of os.PathSeparator, and wondering if that might be related to the issue?

You have to kill guru.exe process to put an end to its misery use of the CPU and memory, unfortunately.

What did you expect to see?

the referrals

What did you see instead?

high cpu and memory usage and Visual Studio Code is waiting for guru.exe to return with results, which does not happen.

@gopherbot gopherbot added this to the Unreleased milestone Feb 18, 2019
@agnivade agnivade changed the title x/tools/guru find references results in high CPU on windows visual studio code x/tools/cmd/guru: find references results in high CPU on windows visual studio code Feb 19, 2019
Copy link

@agnivade agnivade commented Feb 19, 2019

Copy link

@josharian josharian commented Feb 19, 2019

Can you send a SIGQUIT signal to the process a few times and share the resulting stack traces?

Copy link

@MelleKoning MelleKoning commented Feb 19, 2019

Not sure how to do that in Windows 10 64 bit, I do have process explorer that tries to show a stacktrace but shows addresses and threads instead of actual methods/funcs from the stacktrace.

This one is by doing show all references on a method in guru itself, guessImportPath(...), which produces the following command line in Visual Studio Code:

C:\git\go\bin\guru.exe -modified referrers C:\git\go\src\\x\tools\cmd\guru\what.go:#5199

Process explorer shows


Copy link

@MelleKoning MelleKoning commented Feb 21, 2019

Ok, so what I notice is that with find references the entire gopath is being investigated; causes heavy disk usage and CPU. Thought that referrers would only search the currently active go project instead. Is there a reason the entire gopath is being analysed?

Copy link

@MelleKoning MelleKoning commented May 1, 2019

in what way could the /vendor folder be skipped for the 'find all references'?
I'm happy to apply a patch to guru myself but not entirely sure where in what.go a patch would help to accomplish this. The earlier patch by @doxxx only solves searching references on windows starts executing, but loading time is still huge. Therefore looking for quick local improvements...

Copy link

@stamblerre stamblerre commented May 8, 2019

@MelleKoning: We are currently no longer making improvements to guru, as we are focusing efforts on gopls, which will ultimately support finding references. However, we would be happy to review CLs. I believe the change would need to skip vendor directories would need to be made in referrers.go. I'm not too familiar with this code, but it seems that referrers might already be ignoring vendor though? See here.

@gopherbot gopherbot added the Tools label Sep 12, 2019
Copy link

@risentveber risentveber commented Sep 29, 2019

The same problem on Mac, see also fatih/vim-go#2509

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
6 participants
You can’t perform that action at this time.