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 Fixed with Feat: add logger and performance measurement #151
• Add an issue template with instruction to make reporting new issues easier, and allow for easier and more reliable reproduction of issues Fixed with Update log instructions link in bug report template #173
• 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. Fixed with Move to latest prettier with async API #179
• 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.
• 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.

We can also look into moving the heavy work a language server. 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 the language server. 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.

[kevinramharak]

I have been working on a vscode extension that discovers regexes in a workspace and provides a bunch of toolsets to work with them. One of them is checking for redos vulnerable regexes and an early test run shows there are a few regexes in use that are vulnerable:

• /(\([a-zA-Z0-9]*:.*\))/
• /(.*)\.\.\.$/
• /\(param: \/\* (\{ .* \}) \*\//g
• /type x =[ ]?((.|\n)*);.*/g
• /(?<symbol>'.*?') is declared here./

The detection is powered by recheck and easy to confirm in the browser with their playground.

I'm not familiar enough with the theory to fully understand it, but I doubt this is the cause of the performance issues. Nonetheless we should fix these vuln's rather sooner than later.

NOTE: 2 of the 5 are fixed by #186