Tracking: Performance Issues

[kevinramharak]

This issue serves as a central hub for tracking all related performance-related issues and reports.

Goals

• Find & Fix the causes of reported high CPU loads and freezes
• Add & Improve logging to aid in finding performance-related issues
• Add an issue template with instruction to make reporting new issues easier, and allow for easier and more reliable reproduction of issues
• Add (regression) tests to avoid causing the same issues with future changes

Reported issues

• Extension causes the TS Server to stop working #75
• Saving a file is hanging indefinitely #88
• This extension brought vscode to its knees #102
• Extension causes high cpu load #118

Related issues

• formattedMessage cache is obsolete when size > 100 #104

Related PR's

• add logger and performance measurement #138

Resources

• VSCode wiki on performance issues

[kevinramharak]

Some ideas on what could be causing performance issues:

• Regex Dos, could add tests or an eslint plugin like recheck to mitigate potential issues
• prettier@2.x.x is still using a sync API. Based on the provided CPU profiles, it could be a bottleneck. We could migrate to >3.x.x and see how to implement an async aproach.
• As observed in add logger and performance measurement #138 onDidChangeDiagnostics fires a lot, we could investigate if that's intended, and report it to the vscode repo. Often there are no actual changes in diagnostics, thus wasting CPU time. The cache does mitigate a lot of this, but because the implementation still has some flaws (formattedMessage cache is obsolete when size > 100 #104) it could be a bottleneck.
• Some reports mention freezes happening on file save and on refactoring symbols. We should investigate why this happens. My initial assumption is an accidental "DOS" where the changes cause a lot of traffic towards the TS LS, thus triggering a lot of onDidChangeDiagnostics events.

I'm not to familiar with the VSCode runtime, but we can also look into moving the heavy work into a JS Worker or something similar. Where the sync code of onDidChangeDiagnostics would mostly just react to the events and schedule/queue formatting of the diagnostics, and the real work would happen in a worker, or some kind of async queue that leverages the microtask queue of the JS runtime. This could help to prevent a lot of blocking work on the main thread, and thus remove any freezing or slow responsiveness the users experience.