LSP performance issues on "slower" devices

[dekaravanhoc]

Tested versions

• Reproducable in 4.3.stable

System information

Godot v4.3.stable - Windows 10.0.26100 - Vulkan (Mobile) - integrated AMD Radeon(TM) Graphics (Advanced Micro Devices, Inc.; 31.0.21024.2004) - AMD Ryzen 7 7735U with Radeon Graphics (16 Threads)

Issue description

Using the LSP server via NeoVim or VSCode on my laptop results in very slow responses (several seconds) when working with specific scripts in my project.

I have investigated the LSP client-side settings and could not find any differences between files that respond quickly and those with slow responses. Additionally, the project runs without any issues on my desktop PC. Running the LSP server on my desktop and connecting to it from my laptop also eliminates the problem.

File length does not seem to be a factor. Even after deleting the entire content of a problematic file, leaving only the class name and its extends declaration, the slow response persists. Similarly, the number of references to the class does not appear to influence performance. Certain classes consistently cause slow responses, while others resolve normally.

I have also noticed a significant increase in memory usage by Godot when editing files with slow responses—about 2–3 times the usual amount. This behavior does not occur on my desktop PC, even for the same files/classes.

Unfortunately, I don’t have any additional insights at this time, as I haven’t been able to identify a specific cause within the project, the files, or their references. However, it seems there might be a performance issue with the LSP server that the desktop's processing power overcomes but manifests as slow responses on the laptop.

If anyone has experienced a similar issue or can provide guidance on debugging the LSP server side, I would greatly appreciate your help.

Thanks in advance!

Steps to reproduce

Unfortunately not yet.

Minimal reproduction project (MRP)

Unfortunately not yet.

[HolonProduction]

Using the LSP server via NeoVim or VSCode

Did you test the builtin editor? Which LSP request is taking this long (I'd assume autocompletion)?

Additionally, the project runs without any issues on my desktop PC

Is there a noticeable change in CPU activity even when not noticeable from usage?

Also just a hunch, but any change to IO activity on your laptop during the slowdown?

leaving only the class name and its extends declaration

From what are those classes extending? If they extend other scripts the complexity from those scripts might carry over due to the lack of caching as seen in #80637

Does running the LSP on a separate thread (can be configured in the editor settings) make any difference?

If anyone has experienced a similar issue or can provide guidance on debugging the LSP server side, I would greatly appreciate your help.

What I did for #80637 was identifying some action that triggers the slow down. Then I attached a profiler to the godot process for a short period during the slow down (e.g. start profiler, trigger action, wait for result, stop profiler). This at least gives some hint on where Godot is spending its time. (This requires a custom built, since function names are stripped in release builds).

[dekaravanhoc]

Did you test the builtin editor? Which LSP request is taking this long (I'd assume auto-completion)?

Yup. Runs smooth. And yes It is about auto-completion cant see issues with diagnostics and references. It also is slow from the beginning with auto-completion. (In Vim requests only start after insert mode is activated and something is typed. And it is slow starting with the first letter typed.)

Is there a noticeable change in CPU activity even when not noticeable from usage?
Also just a hunch, but any change to IO activity on your laptop during the slowdown?

Only RAM and CPU Usage increase. RAM from about 900MB to 2100-2400MB and CPU from 0%-1% up to 10%. Disk Usage stays the same.

From what are those classes extending? If they extend other scripts the complexity from those scripts might carry over due to the lack of caching as seen in #80637

Already checked this. It does not matter. Happens for In-Build Class extension too. So the only difference I see between scripts with fast auto-completion and ones with slow auto-completion is now basically only - path of the script, name of the class and references of the script somewhere else.

Does running the LSP on a separate thread (can be configured in the editor settings) make any difference?

Checked all the settings too (Smart Resolve, Threads, Time Limit). No impact.

What I did for #80637 was identifying some action that triggers the slow down. Then I attached a profiler to the godot process for a short period during the slow down (e.g. start profiler, trigger action, wait for result, stop profiler). This at least gives some hint on where Godot is spending its time. (This requires a custom built, since function names are stripped in release builds).

Thanks. Got it already set up for custom builds. Ill try look into it. :)