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

[MelleKoning]

go version go1.11.5 windows/amd64

Does this issue reproduce with the latest release?

yes

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:
microsoft/vscode-go#2084

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.

[agnivade]

/cc @josharian @stamblerre

[josharian]

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

[MelleKoning]

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\golang.org\x\tools\cmd\guru\what.go:#5199

Process explorer shows

[MelleKoning]

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?

[MelleKoning]

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...

[stamblerre]

@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.

[risentveber]

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

[adonovan]

guru was deleted in #65880; closing as obsolete.