Slow editing performance on cdt-lsp and visual glitches in editor, especially inlay hints

[voertler]

On eclipse cdt 2024-12 I get bad editing performance for files in the text editor, this leads to inlay hints disappearing randomly, slow code highlighting, and even parenthesis outside the inlay hints disapparing. Also the cursor is flickering, which can take several seconds to go back to normal. Also the outline selection flickers.

When disabling inlay hints in cdt the behaviour is slightly better but also refresh problems occur as can be seen on the fold markers.

Using VSCode with the same clangd server I cannot see similar issues.

When this appears an exception is thrown, which might be related:
java.util.concurrent.CompletionException: org.eclipse.lsp4j.jsonrpc.ResponseErrorException: Request cancelled because the document was modified
at java.base/java.util.concurrent.CompletableFuture.wrapInCompletionException(CompletableFuture.java:323)
at java.base/java.util.concurrent.CompletableFuture.encodeThrowable(CompletableFuture.java:376)
at java.base/java.util.concurrent.CompletableFuture.completeThrowable(CompletableFuture.java:391)
at java.base/java.util.concurrent.CompletableFuture$UniAccept.tryFire(CompletableFuture.java:752)
at java.base/java.util.concurrent.CompletableFuture.postComplete(CompletableFuture.java:554)
at java.base/java.util.concurrent.CompletableFuture.completeExceptionally(CompletableFuture.java:2238)
at org.eclipse.lsp4j.jsonrpc.RemoteEndpoint.handleResponse(RemoteEndpoint.java:220)
at org.eclipse.lsp4j.jsonrpc.RemoteEndpoint.consume(RemoteEndpoint.java:204)
at org.eclipse.lsp4e.LanguageServerWrapper.lambda$3(LanguageServerWrapper.java:314)
at org.eclipse.lsp4j.jsonrpc.json.StreamMessageProducer.handleMessage(StreamMessageProducer.java:185)
at org.eclipse.lsp4j.jsonrpc.json.StreamMessageProducer.listen(StreamMessageProducer.java:97)
at org.eclipse.lsp4j.jsonrpc.json.ConcurrentMessageProcessor.run(ConcurrentMessageProcessor.java:114)
at java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:572)
at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:317)
at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1144)
at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:642)
at java.base/java.lang.Thread.run(Thread.java:1575)
Caused by: org.eclipse.lsp4j.jsonrpc.ResponseErrorException: Request cancelled because the document was modified
... 11 more

[ghentschke]

Thanks for the report. Do you noticed this behavior in previous Eclipse releases as well?

[ghentschke]

Do you have many includes in your file?

[ghentschke]

Which clangd version are you using?

[ghentschke]

Which version of cdt-lsp and lsp4e are you using?

[voertler]

@ghentschke Thanks for your reply

• I'm under windows and tried both the download version of eclipse-cpp-2024-12 and eclipse-cpp-2024-09. Plugins are:
  
• Disabled windows defender
• clangd version is 17, but this version works fine in VisualStudio Code
• The source file has not a lot of includes and is actually the only file in the compile_commands.json, here is the example attached:
  cdt_lsp_slow.zip

It rather seems that something is blocking the display thread, as cursor blinking is also very unregular after moving it by using cursor keys. Also highlighting of same occurences (e.g. function names) can take over 5s after moving around the cursor. During this time it seems that the display thread tries to catch up with a lot of display events leading to graphics bugs. The old non-lsp editor has not this behavior in the same eclipse version.

[voertler]

Now I also checked the Linux version using wsl. There performance is a bit better, however I can also trigger the slow update of inlay hints.

• Rocky 8 under WSL
• Plugins for eclipse-cpp-2024-12
  

[ghentschke]

Unfortunately I cannot reproduce this behavior on my machine. Can you please post your eclipse.ini settings.

[voertler]

@ghentschke Thanks for trying to reproduce this issue. This is the eclipse.ini, which is unmodified from a plain cdt installation, Also under Windows I tried a new clangd version (19.1.6) from mingw64, with exactly the same behavior.

plugins/org.eclipse.equinox.launcher_1.6.900.v20240613-2009.jar
--launcher.library
plugins/org.eclipse.equinox.launcher.win32.win32.x86_64_1.2.1100.v20240722-2106
-product
org.eclipse.epp.package.cpp.product
-showsplash
org.eclipse.epp.package.common
--launcher.defaultAction
openFile
--launcher.appendVmargs
-vm
plugins/org.eclipse.justj.openjdk.hotspot.jre.full.win32.x86_64_21.0.5.v20241023-1957/jre/bin
-vmargs
-XX:CompileCommand=exclude org.eclipse.jdt.internal.core.dom.rewrite.ASTRewriteAnalyzer::getExtendedRange
-Dorg.eclipse.ecf.provider.filetransfer.excludeContributors=org.eclipse.ecf.provider.filetransfer.httpclientjava
--add-opens=java.base/java.io=ALL-UNNAMED
--add-opens=java.base/sun.nio.ch=ALL-UNNAMED
--add-opens=java.base/java.net=ALL-UNNAMED
--add-opens=java.base/sun.security.ssl=ALL-UNNAMED
-Dosgi.requiredJavaVersion=21
[email protected]/eclipse-workspace
-Dosgi.dataAreaRequiresExplicitInit=true
-Dorg.eclipse.swt.graphics.Resource.reportNonDisposed=true
-Declipse.e4.inject.javax.warning=false
-Dorg.slf4j.simpleLogger.defaultLogLevel=off
-Dsun.java.command=Eclipse
-Xms256m
-Xmx2048m
-XX:+UseG1GC
-XX:+UseStringDeduplication
--add-modules=ALL-SYSTEM
-Djava.security.manager=allow
-Djavax.net.ssl.trustStoreType=Windows-ROOT
-Djavax.net.ssl.trustStore=NONE

[ghentschke]

Okay, and maybe a detailed log file please.

[voertler]

Which log file do you mean?

[ghentschke]

Sorry, I mean the *.log file in your workspace .metadata folder which contains the exceptions thrown when you see the behavior mentioned above.

[ghentschke]

@voertler With the latest LSP4E/LSP4J version I can even edit c files with 36.000 lines of code properly. Can you please update and check if you have still troubles?

[ghentschke]

Please try out the LSP4E 0.27.1 release

[voertler]

Sorry, I mean the *.log file in your workspace .metadata folder which contains the exceptions thrown when you see the behavior mentioned above.

I tried to reproduce the issue again and the editing performance problems seem completely unrelated to the error message
java.util.concurrent.CompletionException: org.eclipse.lsp4j.jsonrpc.ResponseErrorException: Request cancelled because the document was modified. In some short test performance was as described without the error message occuring at all.

Regarding the LSP4E update, we will try this and see whether this improves the performance.

[voertler]

@ghentschke Now I tried the update to LSP4E, but I'm not sure whether this worked correctly through the update site however, I'm not sure whether the version is correct. The date seems okay but the plugin version number seems not related to the release:

I also updated LSP4J to the latest version:

Are these the latest version?

Also the performance has not improved. As I mentioned I think the main culprit are the Inlay Hints of clangd and the outline. When I close the outline and disable the hints the performance is much better.

I tried to extend my file to 36000 LoC just for fun and then the performance was basically unusable and also syntax highlighting stopped to work properly, disabling outline and inlay hints made at least editing possible.

Also here is an example eclipse log file of the errors that occur randomly, which might be related:

.log

[ghentschke]

Are these the latest version?

Yes.
Thanks for your reply. I'll take a look into e log. You're right, the request cancelled exceptions are unrelated.

[ghentschke]

Which Eclipse and clangd version are you using?
Please try also the latest cd-lsp build form here: https://download.eclipse.org/tools/cdt/builds/cdt-lsp/main/

[voertler]

Which Eclipse and clangd version are you using? Please try also the latest cd-lsp build form here: https://download.eclipse.org/tools/cdt/builds/cdt-lsp/main/

We tried clangd 15,16,19 using mingw-w64. This seems unrelated, as in comparison VSCode with the clangd plugin works fine with these versions.
The latest cdt-lsp version did not change the behavior.

Another way to trigger slow performance of the lsp based editor is just to try to select 15-20 lines of code by pressing shift+cursor key, this is completely smooth and predictable in the old editor but becomes already a challenge in the LSP based editor. (And this is the same eclipse instance)

[ghentschke]

Another way to trigger slow performance of the lsp based editor is just to try to select 15-20 lines of code by pressing shift+cursor key, this is completely smooth and predictable in the old editor but becomes already a challenge in the LSP based editor. (And this is the same eclipse instance)

Yes, I can confirm that. AFAIK this seems to be a lag due to the communication LS <-> lsp4j/lsp4e and the LS for each selected line.

Edit: You can see this when activating the clangd console under Workspace Preferences -> C/C++ -> Editor (LSP) -> Log to Console:

[voertler]

Thanks for the feedback, the question is whether we should report this to lsp4e or lsp4j. I enabled the communication log for the VSCode clangd plugin (see clangd/vscode-clangd#713 (comment) )and the communication when marking code looks completely different, it seems that not for every line a documentHighlight message is sent.

[ghentschke]

Thanks for the feedback, the question is whether we should report this to lsp4e or lsp4j

Please open an issue in lsp4e

(see clangd/vscode-clangd#713 (comment) )

You can enable the log directly here:

and the communication when marking code looks completely different, it seems that not for every line a documentHighlight message is sent.

Can you please add a snippet of the clangd log here.

BTW: The selection performance of multiple lines is better under Linux. I've tested it under Ubuntu 20.04 and I've seen no lagging.

[voertler]

@ghentschke Thanks for opening and fixing #412 . We will test on our side and I will report back whether it also improves general performance.

[ghentschke]

Okay. As I cannot reproduce this behavior on various machines it would be very nice if you can use a profiler tool like for example the JProfiler to find out what slows down the UI thread so much on you rmachine.

Do you tested vanilla CDT or a vendor implementation using CDT-LSP?

[ghentschke]

I did some code profiling and detected some bottlenecks. I'll provide a PR for that.