Faster LSP loading on slow remote servers #57714
vaqxai
started this conversation in
Feature Requests
Replies: 1 comment
-
|
Same as you. Same PC, same network, same server, everything is same except zed / vscode. I try to ssh my server, 5s with vscode, but 5 min with zed and with unacceptable delay. I like zed cuzz it's fast, low memory. But almost all of my work need to ssh server. I'm curious about why zed is so slowly in ssh. Can zed use the same ssh manner with vscode? If zed can do that, I will uninstall vscode definitely. |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
-
Body
What are you proposing?
I'm proposing additional performance improvements for slow remote SSH servers, especially in concern for LSP servers.
Why does this matter?
When using slow SSH servers, such as ones overseas or on a different continent, when the ping is >200ms, it would be easier to use Zed remotely without having to keep two copies of a project, and would allow to easier work directly on the remote server. Right now, it sometimes takes visible delay (1-2s) for things like suggestions, LSP hints, type hints, etc to appear (tested with basedpyright on python on a server in USA when the developer is in Europe)
Are there any examples or context?
When connecting to a remote in vscode, extensions are partly loaded remotely and partly locally, which allows it to partially bypass this problem.
Possible approach
Zed could download information needed for LSP context (workspace, files, etc) and the entirety of the current file (which it does for editing anyway), and the LSP could, locally, work off of the loaded context. For certain languages, like Rust, this should involve all the information the LSP (like rust analyzer) needs, so config files, source files etc, and for others, like Python, this could simply be the current file + global symbol information.
We could work on the assumption that the files are being mainly edited by the zed user, so we only need to watch for changes for redownload mainly from the user, but also (with perhaps a lower polling rate) for external changes.
The user needs to be aware of the additional disk space, RAM and CPU time used by the LSP running locally, so this should be a well-described opt-in, rather than a default.
Beta Was this translation helpful? Give feedback.
All reactions