Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Investigate changes to LSP pull-diagnostics to make it more efficient. #72868

Open
CyrusNajmabadi opened this issue Apr 3, 2024 · 1 comment
Assignees
Labels
Area-Performance Investigating LSP issues related to the roslyn language server protocol implementation
Milestone

Comments

@CyrusNajmabadi
Copy link
Member

CyrusNajmabadi commented Apr 3, 2024

Right now, the protocol is not efficient at all, sending huge messages, and requiring lots of information to have to be sent back and forth. We should investigate improvements to the protocol to remove redundancy, and allow for the queries that we are passed to be much smaller in scope (like asking for project level diagnostics, not solution level).

Options we should examine:

  1. When possible, not including data, and moving it to a 'resolve' step. A possible candidate for this is Diagnostics.CodeDescription.Href. This is often a large string like "{https://learn.microsoft.com/dotnet/fundamentals/code-analysis/style-rules/ide0055}", on top of the json for "CodeDescription"={"Href"="{https://...}"}. Moving to resolving this only if and when needed by the UI would be helpful.

  2. Moving repetitive data to a common header location. A common example is the information about the associated project for a particular diagnostic which is usually repeated over all diagnostics. This is normally an array like "Projects"=[{"ProjectIdentifier"="...guid...",ProjectName="Potentially.Long.Project.Name"}]. Placing this info about each referenced project up front would allow each diagnostic to then reference these by index, greatly reducing the size.

  3. Moving certain strings to enums. "DiagnosticType"="Style" could just reference a number instead.

  4. Compressing how we encode data. Ranges are the most egregious problem. Needing to send "Range"={"Start"={"Line"=6,"Character"=15},"End"={"Line"=6,"Character"=27}} where "Span"="45,12" would do.

@dotnet-issue-labeler dotnet-issue-labeler bot added Area-Analyzers untriaged Issues and PRs which have not yet been triaged by a lead labels Apr 3, 2024
@CyrusNajmabadi
Copy link
Member Author

Information is extremely promising here. Trying out all of the above, and we drop our message size by 80%.

@sharwell sharwell added Area-Performance Investigating LSP issues related to the roslyn language server protocol implementation and removed Area-Analyzers untriaged Issues and PRs which have not yet been triaged by a lead labels Apr 5, 2024
@sharwell sharwell added this to the Backlog milestone Apr 5, 2024
@CyrusNajmabadi CyrusNajmabadi modified the milestones: Backlog, 17.11 Apr 5, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Area-Performance Investigating LSP issues related to the roslyn language server protocol implementation
Projects
None yet
Development

No branches or pull requests

3 participants