Unnecessarily slow parsing of edits

[friedev]

Steps to reproduce

1. Create a new Godot project.
2. Create a new GDScript file in that project.
3. Open the script in Zed.
4. Insert a large amount of code.
   • In the attached video below, I used Zed's vim mode to do this by typing 200ovar my_long_variable_name: Dictionary<esc>

zed-gdscript-slow.mp4

Expected behavior

The extension processes the most recent contents of the file in one full pass.

In this example, I would expect all the duplicate variables to be marked as errors at the same time, and for there to be no interruption in other language features like autocomplete.

For comparison, you can do the equivalent steps in another language. For instance, make an empty Python script and type something like 200oprint(foo)<esc> (without defining foo) -- all 200 lines are marked as errors simultaneously, and autocomplete continues to work as expected.

godotengine/godot-vscode-plugin behaves this way too.

Actual behavior

The extension appears to process the incoming changes character-by-character (or at least edit-by-edit), which takes a very long time in this case.

The above example is a bit convoluted to make the problem easy to see, but in practice, this occurs in any script of sufficient size, and the implication is that you have to wait for each character you type to be processed individually before completion options are presented. This forces you to wait potentially one second or more each time you want to try to autocomplete something (especially if you're a fast typist), which can be quite a hindrance to productivity.

I'm not a Rust developer or Zed extension developer, so I can't tell exactly what the extension code is doing, but I wonder if it's maybe sending the whole file as a query to language server after each edit, and the language server then has to process each query one by one?

[NathanLovato]

The extension code is not doing anything in this case, it just connects the language server with Zed. You don't have control over much with Zed extensions so that's probably the software behavior.

This happens when simulating a lot of typing, right? This does not happen if you copy and paste a large amount of code, for example? It's quite possible that Zed in this specific case treats every simulated keystroke as a separate edit. It generally does incremental parsing on every keystroke with no debounce, it's immediate.

There are two places to look at here. There's Zed itself. Another would be the language server in Godot itself. I am not sure where this is meant to be handled: Godot likely also tries to process every sent keystroke individually even if they have all been sent simultaneously.

All I can say here is right now extensions have no control over this in Zed. The API just allows us to connect language servers and adapter protocols, and we cannot do much more than that. Adding more control to extension creators is planned in the future.

[friedev]

This happens when simulating a lot of typing, right? This does not happen if you copy and paste a large amount of code, for example?

Correct. Like I said, I used the vim mode to simulate a lot of input just to make the issue more obvious. Pasting only counts as one edit and so it gets parsed in one pass. The real issue is that this delay also happens when you type faster than the language server can keep up with your keystrokes.

I did some digging and found godotengine/godot#89284, which supposedly fixed this exact issue in the Godot language server, but that was over 2 years ago, so I wouldn't expect Godot to be responsible for this issue unless there's been a regression.

The other language servers I've tried in Zed (Python and Deno) have worked fine, and the closest issues I've found are zed-industries/zed#57319 and zed-industries/zed#57242.

You're probably right that there isn't anything you can do in the extension to fix this, though I'm still confused as to why this seems to be happening with Zed + GDScript specifically... I wonder if any clues could be gleaned by comparing the code for this extension to zed-extensions/deno, for instance?

[NathanLovato]

If you check the code of another extension, you'll see that there's really little to them. All they do is say something like "here's the program and shell arguments to run this language server", e.g. deno lsp for deno.

To address something like this, you'd have to first log/trace all the payloads exchanged by zed and the language server, then based on that carefully review all the code that emits the messages and all the code that receives and processes them and find a compromise for how to address this on one of the two ends (zed or godot language server). I think when using a Vim style command that produces keystrokes, probably it shouldn't trigger lots of messages sent from the editor in the first place. But perhaps if you talked with the program maintainers, they have a good reason or a need to do that (or perhaps it's complicated not to do that).

[friedev]

Yeah, you're right. I don't have experience with Wireshark or anything like that, so I doubt I'll get around to troubleshooting it myself in the foreseeable future.

Oh well, I'll go ahead and close this since there's nothing to be done on the extension side. Thanks for your input anyway!

[NathanLovato]

My pleasure!