You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
process.report.getReport is very slow when called in Extension Host, blocks most functionality #238607
I discovered this as part of dprint/dprint-vscode#99; for months my editor has been unresponsive at startup, unable to hover or even copy and paste now that there are paste providers, and this particular call is the culprit.
If I run Node directly, or call VS Code "as node", it does not exhibit these problems. My impression is that this has to do with VS Code patching all of the networking calls, since unfortunately getReport calls to the network (even though effectively all users use it to check if libc is musl or not).
If I run Node directly, or call VS Code "as node", it does not exhibit these problems. My impression is that this has to do with VS Code patching all of the networking calls, since unfortunately getReport calls to the network (even though effectively all users use it to check if libc is musl or not).
If you have an open network socket, ex: a http request with keep alive then it should repro with vanilla node as well.
Reading the relevant Node.js issue and the fix, it seems the extension still needs to call process.report.excludeNetwork = true to avoid the expensive dns resolution calls if they are not interested in the info.
I would also need to backport nodejs/node#55602 so that excludeNetwork covers all cases.
But I don't see how we can completely avoid this issue,
Track and proactively reach out to extensions making report api calls with network info
Flip the default of excludeNetwork in the extension host (this would be a breaking change)
If this is a bug with keepAlive, it doesn't feel like excluding the network stuff would be the "right" fix, of course. But I also doubt it would actually hurt anything...
(This issue doesn't affect me anymore since dprint changed was modified to not use this call when possible)
I mean, sort of, but that's a global option and it has to be set early enough. It sort of sucks that any extension can accidentally freeze the entire editor via this one function, and this one function is used heavily across libraries which have to load native code. The only way to avoid it is to ensure that the global variable is assigned early enough, or ensure that everyone avoids calling it, and so existing code today will still do the wrong thing.
Activity
deepak1556 commentedon Jan 24, 2025
Thanks for the concise repro, I will try backporting the upstream fix and see if that helps.
deepak1556 commentedon Jan 24, 2025
If you have an open network socket, ex: a http request with keep alive then it should repro with vanilla node as well.
Reading the relevant Node.js issue and the fix, it seems the extension still needs to call
process.report.excludeNetwork = trueto avoid the expensive dns resolution calls if they are not interested in the info.I would also need to backport nodejs/node#55602 so that excludeNetwork covers all cases.
But I don't see how we can completely avoid this issue,
/cc Christof Marti (@chrmarti) Alexandru Dima (@alexdima)
jakebailey commentedon Jan 24, 2025
Interesting; this vaguely reminds me of nodejs/node#47228
The hang requiring some other ongoing request sort of explains why this happens to me more consistently when Copilot is enabled...
jakebailey commentedon Jan 24, 2025
If this is a bug with keepAlive, it doesn't feel like excluding the network stuff would be the "right" fix, of course. But I also doubt it would actually hurt anything...
(This issue doesn't affect me anymore since dprint changed was modified to not use this call when possible)
deepak1556 commentedon Apr 17, 2025
Closing as there isn't much we can do here, nodejs/node#55602 is available in 1.99 so extensions can use to avoid the dns resolution calls.
jakebailey commentedon Apr 17, 2025
I mean, sort of, but that's a global option and it has to be set early enough. It sort of sucks that any extension can accidentally freeze the entire editor via this one function, and this one function is used heavily across libraries which have to load native code. The only way to avoid it is to ensure that the global variable is assigned early enough, or ensure that everyone avoids calling it, and so existing code today will still do the wrong thing.