fix: enable compression for large messages#15
Merged
Conversation
Full completions when mathlib is imported can be on the order of 200k items, on the order of 20-40MB jsonrpc responses. Because these are on the same websocket connection as `$/lean/fileProgress`, we will block on transferring the completions response before communicating to the user that elaboration has finished successfully. This sometimes leads to reportedly 10-30s user-visible latency between finishing typing and waiting for the yellow spinner in the infoview to resolve. In practice, completions appear to be compressed by a factor of 8-9x by the deflate algorithm supported by websockets. We expect this should improve user-facing (non-completion) responsiveness when large completions are in flight, as other factors such as JSON.parse or toString are measured as negligible (well under 100ms) for the same payload. It may also improve end-to-end completion responsiveness itself, but probably at most only by a factor of about 2x according to experiments.
robsimmons
self-requested a review
July 16, 2026 17:36
robsimmons
approved these changes
Jul 16, 2026
robsimmons
left a comment
robsimmons
left a comment
Collaborator
There was a problem hiding this comment.
What a wonky set of defaults (w.r.t threshold/{server,client}Takeover). Hopefully this will help - it might make sense to see if you can get similar performance wobbles on Jon's server which would indicate we should upstream this.
Collaborator
Author
|
Oh yeah perhaps I should make a parallel upstream PR; I was thinking of prioritizing empirical testing by bhavik, but there's no reason not to seek feedback from both concurrently. |
Collaborator
Author
|
I'm pushing a revert just to see if the null PR still exhibits the same test failures reliably. |
jcreedcmu
force-pushed
the
nixos-jcreed-compress
branch
from
July 16, 2026 18:02
e90d98a to
add3dba
Compare
Collaborator
Author
|
The revert had the same test failure. I conclude therefore that the failure is not related to this PR. |
This file contains hidden or 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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
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.
Full completions when mathlib is imported can be on the order of 200k items, on the order of 20-40MB jsonrpc responses. Because these are on the same websocket connection as
$/lean/fileProgress, we will block on transferring the completions response before communicating to the user that elaboration has finished successfully. This sometimes leads to reportedly 10-30s user-visible latency between finishing typing and waiting for the yellow spinner in the infoview to resolve.In practice, completions appear to be compressed by a factor of 8-9x by the deflate algorithm supported by websockets. We expect this should improve user-facing (non-completion) responsiveness when large completions are in flight, as other factors such as JSON.parse or toString are measured as negligible (well under 100ms) for the same payload. It may also improve end-to-end completion responsiveness itself, but probably at most only by a factor of about 2x according to experiments.