lsp: Parse LSP messages on background thread - again #23122
Merged
+83
−62
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
cla-bot
bot
added
the
cla-signed
osiewicz
force-pushed
the
parse-lsp-messages-on-background-thread
branch
3 times, most recently
from
a9944c3 to
f452cfb
Compare
This is a follow-up to #12640. While profiling latency of working with a project with 8192 diagnostics I've noticed that while we're parsing the LSP messages into a generic message struct on a background thread, we can still block the main thread as the conversion between that generic message struct and the actual LSP message (for use by callback) is still happening on the main thread. This PR significantly constrains what a message callback can use, so that it can be executed on any thread; we also send off message conversion to the background thread. This has improved throughput of my 8192-benchmark from 40s to send out all diagnostics after saving to ~20s. Now main thread is spending most of the time updating our diagnostics sets, which can probably be improved.
osiewicz
force-pushed
the
parse-lsp-messages-on-background-thread
branch
from
f452cfb to
decb198
Compare
ConradIrwin
added a commit
that referenced
this pull request
Jan 17, 2025
This reverts commit 1b3b825.
ConradIrwin
added a commit
that referenced
this pull request
Jan 17, 2025
#23301) This reverts commit 1b3b825. When debugging git diffs we found that this introduced a re-ordering of messages sent to the LSP: * User hits "format" * Zed adjusts spacing, and sends "spaces changed" to the LSP * Zed sends "format" to LSP With the async approach here, the format request can now arrive before the space changed request. You can reproduce this with `test_strip_whitespace_and_format_via_lsp` under some conditions. Release Notes: - N/A
osiewicz
added a commit
that referenced
this pull request
Jan 17, 2025
osiewicz
added a commit
that referenced
this pull request
Jan 17, 2025
As @ConradIrwin found out in #23301 the LSP messages could be processed out of order after #23122; this PR makes our approach to event processing a bit more conservative - instead of detaching the parsing task we'll now await them in the main loop. This keeps the benefit of #23122 in that deserialization still happens off the main thread, but some of the performance benefit of #23122 could've been a result of the buggy interaction that Conrad discovered.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This is a follow-up to #12640.
While profiling latency of working with a project with 8192 diagnostics I've noticed that while we're parsing the LSP messages into a generic message struct on a background thread, we can still block the main thread as the conversion between that generic message struct and the actual LSP message (for use by callback) is still happening on the main thread.
This PR significantly constrains what a message callback can use, so that it can be executed on any thread; we also send off message conversion to the background thread. In practice new callback constraints were already satisfied by all call sites, so no code outside of the lsp crate had to be adjusted.
This has improved throughput of my 8192-benchmark from 40s to send out all diagnostics after saving to ~20s. Now main thread is spending most of the time updating our diagnostics sets, which can probably be improved too.
Closes #ISSUE
Release Notes: