Slow sequential processing after each typed char

[smanolloff]

Describe the bug

After the latest update, I noticed that LSP got a lot slower in my project because it triggers on each typed character. This leads to many events triggered, queued and executed sequentially, sometimes causing delays of several seconds, until the last character of the word gets processed.

Expected behavior

Processing triggers some time after I stop typing, e.g. 1 second (ideally: configurable), after I have finished typing the word

Screenshots

lsp2-720.mov

Logs

lsp.log

Environment (please complete the following information):

• OS: MacOS 26.2
• Sublime Text version: 4200
• LSP version: v2.11.0
• Language servers used: clangd

Additional context

No custom settings. I tried with diagnostics_delay_ms and diagnostics_additional_delay_auto_complete_ms but these do not seem to make any difference for this issue.

I am grateful for your work on LSP. Having it available for ST is a real game changer for me. Thank you.

[predragnikolic]

Hello. Thanks for the report.

Did you experience such issues with the last release as well:
https://github.com/sublimelsp/LSP/releases/tag/4070-2.10.2

Or only with the new v2.11.0 release?

[rwols]

Can you list all packages you have installed?

[smanolloff]

Hello,

Or only with the new v2.11.0 release?

I am sure this popped up after the latest update (v2.11.0). I never noticed anything similar before and I work on this project on a daily basis. Whether the pre-update version was v2.10.2 I cannot be certain, but since Package Control automatically updates all packages to newest versions, I assume it has been. I will try to set up the older package version to see if I can confirm that for you.

Can you list all packages you have installed?

Below is the installed_packages contents from my Package Control.sublime-settings:

    [
      "Advanced CSV",
       "CMake",
       "Dockerfile Syntax Highlighting",
       "FileDiffs",
       "fish",
       "LSP",
       "LSP-clangd",
       "LSP-json",
       "LSP-pylsp",
       "MarkdownPreview",
       "Package Control",
       "PackageResourceViewer",
       "Pretty JSON",
       "SortBy",
       "TrailingSpaces"
    ]

[smanolloff]

Can you help me install an older version?
Here is what I tried:

1. Quit ST
2. Remove LSP and LSP-clangd from Package Control
3. Manually checkout the LSP repo into the Packages directory (~/Library/Application Support/Sublime Text/Packages)
4. Start ST

However, that doesn't seem to work - I see some errors in the ST console

Traceback (most recent call last):
  File "/Applications/Sublime Text.app/Contents/MacOS/Lib/python38/sublime_plugin.py", line 324, in reload_plugin
    m = importlib.import_module(modulename)
  File "./python3.8/importlib/__init__.py", line 127, in import_module
  File "<frozen importlib._bootstrap>", line 1014, in _gcd_import
  File "<frozen importlib._bootstrap>", line 991, in _find_and_load
  File "<frozen importlib._bootstrap>", line 975, in _find_and_load_unlocked
  File "<frozen importlib._bootstrap>", line 671, in _load_unlocked
  File "<frozen importlib._bootstrap_external>", line 868, in exec_module
  File "<frozen importlib._bootstrap>", line 219, in _call_with_frames_removed
  File "/Users/simo/Library/Application Support/Sublime Text/Installed Packages/LSP-json.sublime-package/commands.py", line 4, in <module>
ImportError: cannot import name 'Error' from 'LSP.plugin' (/Users/simo/Library/Application Support/Sublime Text/Packages/LSP/plugin/__init__.py)
reloading plugin LSP-json.plugin
Traceback (most recent call last):
  File "/Applications/Sublime Text.app/Contents/MacOS/Lib/python38/sublime_plugin.py", line 324, in reload_plugin
    m = importlib.import_module(modulename)
  File "./python3.8/importlib/__init__.py", line 127, in import_module
  File "<frozen importlib._bootstrap>", line 1014, in _gcd_import
  File "<frozen importlib._bootstrap>", line 991, in _find_and_load
  File "<frozen importlib._bootstrap>", line 975, in _find_and_load_unlocked
  File "<frozen importlib._bootstrap>", line 671, in _load_unlocked
  File "<frozen importlib._bootstrap_external>", line 868, in exec_module
  File "<frozen importlib._bootstrap>", line 219, in _call_with_frames_removed
  File "/Users/simo/Library/Application Support/Sublime Text/Installed Packages/LSP-json.sublime-package/plugin.py", line 8, in <module>
ImportError: cannot import name 'command_handler' from 'LSP.plugin' (/Users/simo/Library/Application Support/Sublime Text/Packages/LSP/plugin/__init__.py)
reloading plugin LSP-json.schema_store
reloading plugin LSP-pylsp.plugin
Traceback (most recent call last):
  File "/Applications/Sublime Text.app/Contents/MacOS/Lib/python38/sublime_plugin.py", line 324, in reload_plugin
    m = importlib.import_module(modulename)
  File "./python3.8/importlib/__init__.py", line 127, in import_module
  File "<frozen importlib._bootstrap>", line 1014, in _gcd_import
  File "<frozen importlib._bootstrap>", line 991, in _find_and_load
  File "<frozen importlib._bootstrap>", line 975, in _find_and_load_unlocked
  File "<frozen importlib._bootstrap>", line 671, in _load_unlocked
  File "<frozen importlib._bootstrap_external>", line 868, in exec_module
  File "<frozen importlib._bootstrap>", line 219, in _call_with_frames_removed
  File "/Users/simo/Library/Application Support/Sublime Text/Installed Packages/LSP-pylsp.sublime-package/plugin.py", line 3, in <module>
ImportError: cannot import name 'LspPlugin' from 'LSP.plugin' (/Users/simo/Library/Application Support/Sublime Text/

I don't really know what is the correct way to install a specific package version, so I can't test it.

[rchl]

The checkout out LSP repo is either somehow not there or on wrong branch. It should be on the latest main branch.

Are there any other errors before the one you've posted?

[smanolloff]

The checkout out LSP repo is either somehow not there or on wrong branch. It should be on the latest main branch.

Why should it be on the latest main branch? The goal was to install an older version - so I checked out a specific tag, in this case 4070-2.10.2.

I believe the error might have been due to a stray lsp_utils package (from an old release maybe). Either way, repeating the experiment - this time removing all LSP-like packages and servers, starting fresh, allowed me to test with 4070-2.10.2, then again with 4070-2.11.0 to confirm the issue.

Below are two screen recordings + logs (from the last typed line only), you can clearly see the difference. Sorry for the potato quality, github doesn't allow me to upload large video files here.

Test 1: old version (4070-2.10.2) - fast

The line is processed almost immediately after I am done typing.

Logs: lsp-old-fast.log
Potato recording 1:

lsp-old-fast-480.mov

Test 2: latest version (4070-2.11.0) - slow

The line is processed in no less than 5 seconds after I am done typing.

Logs: lsp-new-slow.log
Potato recording 2:

lsp-new-slow-480.mov

What strikes me as an obvious hint in the logs are these lines (present in the old version only):

clangd: I[11:31:49.409] --> reply:textDocument/documentLink(99) 958 ms, error: Task was cancelled.
clangd: I[11:31:49.409] --> reply:textDocument/documentLink(101) 574 ms, error: Task was cancelled.
clangd: I[11:31:49.409] --> reply:textDocument/documentLink(103) 489 ms, error: Task was cancelled.
clangd: I[11:31:49.409] --> reply:textDocument/documentLink(105) 447 ms, error: Task was cancelled.

It seems with the new version, those tasks are awaited until they complete which might be the culprit.

[jwortmann]

We declare now that we support to cancel requests, which we do iirc for completions, semantic tokens, document (pull) diagnostics, and code lens resolve.

LSP/plugin/core/sessions.py

Lines 343 to 346 in 01dbb02

	"staleRequestSupport": {
	"cancel": True,
	"retryOnContentModified": []
	},

		/**
		 * Client capability that signals how the client
		 * handles stale requests (e.g. a request
		 * for which the client will not process the response
		 * anymore since the information is outdated).
		 *
		 * @since 3.17.0
		 */
		staleRequestSupport?: {
			/**
			 * The client will actively cancel the request.
			 */
			cancel: boolean;

			/**
			 * The list of requests for which the client
			 * will retry the request if it receives a
			 * response with error code `ContentModified``
			 */
			 retryOnContentModified: string[];
		}

But I think we don't actively cancel requests for document link, and perhaps the server now behaves differently based on the cancel: True flag being set, i.e. previously it would automatically cancel its own tasks on didChange, but apparently it doesn't do that anymore.

[jwortmann]

As a workaround you could try

{
    "link_highlight_style": "disabled",
}

in LSP settings to disable document link functionality and then see if the lagging is gone.

[smanolloff]

Yes, it seems the lagging is gone now. I even like it visually better without that highlight.

This workaround works well for me, thank you.

[rchl]

Why should it be on the latest main branch? The goal was to install an older version - so I checked out a specific tag, in this case 4070-2.10.2.

True. Then the error is expected because LspPlugin did not exist there yet and some packages were updated to use it already (doesn't affect LSP-clangd though).

[jwortmann]

I voted to not use the underline style as default setting for the links, but I got outvoted on that decision :)

We could try to add cancelling support for documentLink and (and probably for other requests too), but I think using cancel: True in the client capabilities is still the right thing, because we do that for several other requests already.

And the question is also why does the server need 5-6 seconds to handle document link requests. I would assume that this should be a relatively simple request and it should only take a few milliseconds to compute. With that long time it takes in clangd, I would even suggest to disable the documentLinkProvider capability by default in the LSP-clangd config, because even with the former behavior it seems that it would use a lot of CPU time or drain battery for laptop users if that happens after each document change while typing.

[jwortmann]

Actually from the logs (and video recording) you can see that each subsequent textDocument/documentLink request takes more and more time to compute. Something like 300ms more on each new request. So it looks like that there is also some pretty serious bug in the server.