-
Notifications
You must be signed in to change notification settings - Fork 647
High CPU utilization at almost every save #3110
Comments
@wtask It seems that gopls is using quite bit of memory and cpu.
|
@hyangah I updated my |
If you are working on a public project, could you share a link to the repository so we can try to repro? |
@stamblerre GOPRIVATE is set for this project |
@stamblerre I can also confirm bug. It can be observer with latest relase of gopls as well as version from master. I think it can be related to case when you have modules enabled but still vendor exists in project. |
@tobiaszheller thanks for sharing the repro case. @stamblerre here is the gopls log Related - we got another issue related the behavior change during file save after upgrade of vs code (1.43). The other issue was closed because it was due to another extension, but I wonder if there was a change in VS Code's save function and that tickled underlying issues. |
Wanted to leave a note about the output i see from gopls on save events -- which only started happening after the upgrade. and it does this constantly causing high load and crashes the window most of the time.
My System:
|
@tobiaszheller In my case there are neither vendor folders inside project dirs |
@anykine29 Are all those 10123 lines the log messages after the file save? Can you share that output? I think we need to ask vscode team. I see some issue reports coming in to microsoct/vscode issue tracker, related to the behavior changes on save, but better trace data may help for them to triage. |
Correct those 10k lines are as I try to save the file. |
@hyangah I cannot publish current log due to project specific requirements. But in the log I saw tons of dummy gopls-processing with files in the .history/ folder. So the current issue may be related to #3036 (workspace/didChangeWatchedFiles). I have to disable the |
@anykine29 thanks! I filed a new upstream issue based on your trace. Are you using any other go extension by any chance? @stamblerre The trace I generated using @tobiaszheller's repro case exhibits a different issue and I want gopls-devs to take a look. It shows significant slow down after background refresh. background refresh: 5sec |
@hyangah Thanks! And here are my go ext: |
@anykine29 thanks - according to #3109, Go Group Imports extension may be problematic. The gopls-debug can be disabled too (that's a test version of Go extension and doesn't add additional functionalities other than what Go extension offers already). I don't know much about other extensions, but turning on one by one until the problem reappears is one option for debugging. |
@hyangah I was also using Go Group Imports extension, but the issue still exists, even though extension was disabled. I have also checked and there were not changes to that extension since December. I guess something (vscode?) is triggering a lot of new events what's causing those extension to run all the time. |
Sorry for not being more active on this issue - just trying to parse through the different cases here. @anykine29: This issue does sound like the bug with Go Group Imports. Please let us know if disabling that extension resolved the issue (you can get similar behavior with @wtask: Does disabling the Local History extension completely resolve the problem? If so, then this issue sounds like a duplicate of #3036 as you said. I'd recommend following along with golang/go#37697 for updates on that issue. Hopefully we will be able to come up with a reasonable approach for future
Yes, there have been some changes in the way that VS Code handles on-save actions. I tried to reproducing this issue, and I think the problem is simply that running |
@stamblerre Sometimes I see the code actions popup for a few seconds, but the critical delay has disappeared |
Thanks for letting me know! I've seen that pop-up myself a few times, so I'll try to do some more investigating when I see it next. If you see any code action requests that take longer than you'd expect, please report them. |
Same problem. Just want to share my observation that the problem rises when working with even trivial Bazel-workspaces. I think that for proper operation all |
@lazdmx: Right now, we don't officially support Bazel in |
This issue has been closed automatically because it needs more information and has not had recent activity. Thank you for your contributions. |
What version of Go, VS Code & VS Code Go extension are you using?
go version
to get version of Gocode -v
orcode-insiders -v
to get version of VS Code or VS Code InsidersCommit: 78a4c91400152c0f27ba4d363eb56d2835f9903a
Date: 2020-03-09T19:47:57.235Z
Electron: 7.1.11
Chrome: 78.0.3904.130
Node.js: 12.8.1
V8: 7.8.279.23-electron.0
OS: Windows_NT x64 10.0.18363
Describe the bug
I have a project with different workspace folders. Very often after making some changes I press Ctrl+S. And after that my laptop begins execute very hard job which consumes 100% CPU utilization. I don't understand which the underlying tasks are running by vscode-go extension at this moment, but 4 cores with 32 Gb RAM works very slow and make me crazy why the file saving is for 3-4 minutes. Also, I see an abnormal behaviour of Windows Defender when vscode-go is saving file. Perhaps the Antimalware Service Executable does not trust for gopls-processes.
Screenshots or recordings
The text was updated successfully, but these errors were encountered: