Language server takes a long time to respond to requests

[samestep]

For instance, here is a snippet of the message log from v1.10.0 of the Slang VS Code extension, after setting "slangLanguageServer.trace.server": "messages" and saving main.slang from juliusikkala/slang-simple-vulkan:

[Trace - 3:43:55 PM] Sending request 'textDocument/formatting - (10)'.
[Trace - 3:43:55 PM] Sending request 'textDocument/inlayHint - (11)'.
[Trace - 3:43:55 PM] Sending notification '$/cancelRequest'.
[Trace - 3:43:55 PM] Sending request 'textDocument/inlayHint - (12)'.
[Trace - 3:43:55 PM] Sending request 'textDocument/documentSymbol - (13)'.
[Trace - 3:43:56 PM] Sending request 'textDocument/semanticTokens/full - (14)'.
[Trace - 3:43:58 PM] Received response 'textDocument/completion - (8)' in 3801ms.
[Trace - 3:43:58 PM] Received notification 'window/logMessage'.
[Info  - 3:43:58 PM] Server processed 2 commands, executed in 3768ms
[Trace - 3:43:58 PM] Received response 'textDocument/documentSymbol - (9)' in 3465ms.
[Trace - 3:43:58 PM] Sending request 'completionItem/resolve - (15)'.
[Trace - 3:43:58 PM] Received response 'textDocument/formatting - (10)' in 3427ms.
[Trace - 3:43:58 PM] Received response 'textDocument/inlayHint - (11)' in 3224ms. Request failed:  (-32800).
[Trace - 3:43:58 PM] Received response 'textDocument/inlayHint - (12)' in 3049ms.
[Trace - 3:43:58 PM] Received response 'textDocument/documentSymbol - (13)' in 2872ms.
[Trace - 3:43:58 PM] Received response 'textDocument/semanticTokens/full - (14)' in 2434ms.

The one I initially noticed was the textDocument/formatting request, because I have "editor.formatOnSave": true and so this is causing a multiple-second delay every time I try to save a *.slang file. However, this log also shows several other requests taking a similarly long time.

I tested this on x86 Ubuntu. Some things I tried that did not change anything:

• Just wait and keep editing/saving the file in case the language server was still indexing/caching things.
• Explicitly set slang.slangdLocation to point to a prebuilt binary I downloaded from the Slang v2025.12.1 release.
• Remove clang-format from my PATH in case formatting itself is just taking a long time.

[csyonghe]

I would appreciate if somebody can run profiling to see what is taking so long.

[csyonghe]

I tried this myself on my Windows machine, and everything is running fast. At least I am not able to sense any latency with auto-completion:

Not sure if it is a linux specific issue, or if there are any other specific configurations on your machine/workspace.

[csyonghe]

One potential reason for the slowness could be that your workspace has a lot of subdirectories. Slang will look for all subdirectories when searching for an imported file. If there are too many subdirectories, the system calls to find the file can take up a long time.

[csyonghe]

Update: I tried this under WSL ubuntu and reproduced the slowness. Definitely looks like it is OS specific.

[csyonghe]

Unfortunately I can't setup profiling on my WSL environment, so we will need help from somebody who have a working linux environment to profile this.

[ArielG-NV]

If you just need to profile and only have WSL, I find hotspot works pretty well with WSL.

[csyonghe]

@ArielG-NV it seems to require perf, which isn't available on wsl?

[ArielG-NV]

perf has to be compiled manually

[ArielG-NV]

I suppose if we want a proper profile a proper Ubuntu system (or VM) should be used anyways...

[csyonghe]

I figured a way to setup perf on WSL, and looking at the profiling results, there isn't any obvious bottlenecks, just systematically slower than Windows.

[juliusikkala]

In this specific file, the Vulkan & SDL binding files are one factor that may affect this. They are massive (especially the generated union wrappers using lots of property and reinterpret trickery), and they seem to significantly slow down the compiler and probably the language server as well. They're generated during the build.

[samestep]

@juliusikkala that was my guess too; I don't understand the compiler / language server architecture well enough to see why that would make it so slow on edits to main.slang though. Shouldn't separate compilation make it still be fast since vulkan.slang is a separate module? Also Yong said this issue doesn't occur on Windows (although he didn't post the message log so we don't have specific numbers there).