Closed evan-kochuk-niche closed 4 months ago
@evan-kochuk-niche Do you remember the go version and the delve version you used before and now?
Delve v1.22.1 (Go debugger) was released last week. If you install the previous version, do you see any difference?
go install github.com/go-delve/delve/cmd/dlv@v1.22.0
The unit tests on my production code takes even longer, on the order of minutes, also on variable assignment.
Do you mean that unit tests in debugging mode?
Is it fast when you use the command line tool for debugging? dlv debug
@evan-kochuk-niche Do you remember the go version and the delve version you used before and now?
I have not updated my go version from 1.21 in months. Delve is just set to use @latest
Delve v1.22.1 (Go debugger) was released last week. If you install the previous version, do you see any difference?
Gave it a shot; I do not.
The unit tests on my production code takes even longer, on the order of minutes, also on variable assignment.
Do you mean that unit tests in debugging mode? Is it fast when you use the command line tool for debugging?
dlv debug
Yes, in debugging mode (as per clicking "Debug test" above the function in the screenshot). This is only an issue when a breakpoint is set. If no breakpoint is set, the test finishes in under a second.
Can you try dlv debug
commandline, to see if it perform this bad?
Last week release carries a change that just disables installation of a helper binary on windows, and that is unrelated to debugging. I don't recall any memorable change in v0.41.0 release either. Is there any OS update or system library update in your windows that may cause a different behavior or introduce extra checks when programs are debugged?
I have been able to confirm that running dlv debug
via commandline has no performance degradation.
Only the golang debugging inside of VS Code is affected (and only then when a breakpoint is hit). And it is only the go debugging -- C# debugging in VS Code is unaffected.
My organization's IT department claims that there were no recent updates pushed out to our machines, but I don't have any details more than that. I'm kinda stumped; never seen anything like this before.
I don't know if this will show any more info, but how about collecting logs?
"go.delveConfig": {
"logOutput": "dap,debug",
"showLog": true,
},
This will cause to print out timestamped log messages in the DEBUG CONSOLE panel.
I think this can probably be closed.
I experimented with a different IDE entirely -- GoLand -- and am observing the same breakpoint behavior, which makes me think that whatever issues I'm encountering, they are not tied to VS Code, but either Delve or some hardware issue.
Thanks for the update. Closing.
What version of Go, VS Code & VS Code Go extension are you using?
Version Information
* Run `go version` to get version of Go from _the VS Code integrated terminal_. - **go1.21.0 windows/amd64** * Run `gopls -v version` to get version of Gopls from _the VS Code integrated terminal_. - golang.org/x/tools/gopls v0.14.2 * Run `code -v` or `code-insiders -v` to get version of VS Code or VS Code Insiders. - 1.86.2 * Check your installed extensions to get the version of the VS Code Go extension - v0.41.1
Share the Go related settings you have added/edited
None.
Describe the bug
I'm experiencing vastly degraded performance when using the VSCode debugger compared to last week.
When debugging with breakpoints set, performance drops by orders of magnitudes. For the following unit test:
A breakpoint is set on the y variable assignation, at which point pressing stepover (F10) takes 10 seconds to reach the next line. The unit tests on my production code takes even longer, on the order of minutes, also on variable assignment.
Before Thursday or Friday of last week (2024-22-02), such a stepover command executed nigh instantly. The VS Code debugger for other languages appears unaffected (the C# extension I tested with handled a similar test instantaneously, as expected). This is affecting other developers in my organization also using VSCode, so I don't think this can be hardware issue specific to me.
I noticed there was an update to the Go extension published last week at about the same time I started encountering this problem, but despite rolling back to 41.0 or 40.3, I still experienced this problem.
To clarify, this was working just fine last week -- this is some sort of acute change, and I have no idea how to further diagnose what is going wrong.
Steps to reproduce the behavior:
Screenshots or recordings