Performance optimization#230804
Conversation
|
@microsoft-github-policy-service agree |
|
I'm not sure how your PR description relates to the code you changed. Your code is in Cancellation is not requested when disposing a CancellationTokenSource by default so I'm not sure that I see where the problem is occurring -- were you able to verify what you say actually happens when debugging the server? |
I apologize for the confusion. The code in requestEvent is a different part; what I described in the PR pertains to the code within requestPromise. As you mentioned, disposing of the Here’s what happened during debugging: debug.mp4 |
Co-authored-by: Connor Peet <connor@peet.io>
|
Thanks for the PR! |
Hello VSCode team.
I've made some performance optimizations and the most impactful change is here:
Why?
Before the modification, the
cancelfunction was added to the disposable. In my understanding, thiscancelfunction should be used to promptly cancel the request when a cancellation occurs.However, when the request has not been canceled and a response is received, the result promise reaches the finally phase:
This is what the cancel function does:
On the server side, the received requests are cleaned up after processing, meaning that each cancellation request triggered by the client results in an unnecessary cleanup on the server.
In summary, I believe that the cancellation requests here are meaningless and occur almost for every request established through IPC communication.
This situation started occurring after this change.