Drastic performance improvements when indexing IntelliJ files

[angelozerr]

After spending hours and hours trying to fix the problem we have with our MicroProfile LS and Qute LS language server redhat-developer/intellij-quarkus#1373 I intend to make a major change in LSP4IJ. This will not impact the API (I hope) but rather:

• the behavior of language server startups (for most language servers)
• and for our language servers (that delegate data computation (e.g. displaying codelens in java files) to IntelliJ to visit Java files) the execution of some LSP features (codelens, highlight, etc).

Start the language servers after the "Scannings files to index..." process

After having carried out numerous tests, I was able to notice that if we open several projects which must start several language servers and that when opening each project which opens editors which had not been closed during the previous closing of IntelliJ, IntelliJ launches its process of "Scannings files to index...", the performances are catastrophic!

To have better performance, we should start language servers after the "Scannings files to index..." process

This new behavior would be done by default, but if I can do it I would like to be able to provide a new method in the LSPCLientFeature that would disable this behavior to go back to the way it was before if you ever want to have your language server available as soon as possible (but this will impact IntelliJ launch performance if it runs "Scannings files to index...".

To set up this mechanism, it is a real challenge because the launch of the language servers is done

• when the editor opens. This is easy to disable.
• or when the editor asks to display CodeVision, Highlight, SemanticTokens. On this point we do not have control and this makes it complicated to set up the mechanism.

I created a POC at https://github.com/redhat-developer/lsp4ij/pull/570/files which when the editor opens, waits via a CompletableFuture for the indexing to be finished, to then start the language server, which then performs a didOpen. But the editor that opens asks to display the CodeVision which also forces the start of the language server which waits for the didOpen to be done (hence the IntelliJ freezes). In my POC I disabled the codelens, highlight when there is an indexing that is being done. This allows IntelliJ to do its idexation, then start the language servers once the indexing is finished. As a result, the codelens are not displayed. If we refresh the editor by modifying its content, the codelens are displayed again. I need to study how we can manage that.

This is where there is a big challenge: refreshing the codelens, highlight, etc. when the indexing is finished.

Technically, to set up this mechanism you need to know when the file indexing and dumb mode have finished. My first tests were to use DumService.isDumb(Project) and runWhenSmart which failed.

Indeed these 2 methods work well when IntelliJ is in dumb mode but not when it is executing the "Scannings files to index...". I managed to know when IntelliJ is in indexing state by by implementing ProjectIndexingActivityHistoryListener (see my PR https://github.com/redhat-developer/lsp4ij/pull/570/files).

Execution of some LSP features only when IntelliJ is not indexing

This point should not concern you if your server language does not delegate the parsing of the document to IntelliJ.

In the case of MicroProfile LS, Qute LS delegates the calculation of Codelens in Java files to IntelliJ to visit these files and know where the codelens should be displayed and their contents calculated according to the Java field names etc.

Since we are visiting Java files, we must do so only if the indexing is complete. The editor asks to display CodeVision, this calls our language servers which should not return anything if there is an indexing. When the indesaction ends (and the content of the editor has not changed since), this must refresh the codelens by visiting the Java files which are indexed correctly and which allows to avoid this error redhat-developer/intellij-quarkus#1373

For us this is very important for our IntelliJ Quarkus plugin and we need to have this feature as soon as possible because many users are complaining about all these errors.

But I don't know when I will be done with it, so maybe it would be more prudent to create a LSP4IJ 0.7.0 release next week for example. @fbricon what do you think about that?

cc @CppCXY @InSyncWithFoo @seachicken @KUGDev @AlexWeinstein92 @aparnamichael @MituuZ @turkeylurkey @mrglavas @koxudaxi @FalsePattern @onriv @kristofvb @themartdev @kdvolder please follow this important discussion.

[mrglavas]

@angelozerr We were just discussing this PR yesterday though from the perspective of a pain point we've had with automated testing. The UI robot we're using tries to interact with the editor to look at diagnostics, apply quick fixes, check the text in hover, etc... and indexing makes the timing of all that challenging. Seems like this could also be a great programmatic solution for writing reliable tests.

[angelozerr]

@angelozerr We were just discussing this PR yesterday though from the perspective of a pain point we've had with automated testing. The UI robot we're using tries to interact with the editor to look at diagnostics, apply quick fixes, check the text in hover, etc... and indexing makes the timing of all that challenging. Seems like this could also be a great programmatic solution for writing reliable tests.

I dont know if my work will help you since the idea is to say display codelens after the indexing is finished.

When I have investigate how to know when index is finished I have found this https://github.com/JetBrains/intellij-community/blob/master/platform%2FtestFramework%2Fsrc%2Fcom%2Fintellij%2FtestFramework%2Ffixtures%2Fimpl%2FCodeInsightTestFixtureImpl.java#L338

Perhaps using this method or copy it in your code base could resolve your timing problem?

[mrglavas]

@angelozerr We were just discussing this PR yesterday though from the perspective of a pain point we've had with automated testing. The UI robot we're using tries to interact with the editor to look at diagnostics, apply quick fixes, check the text in hover, etc... and indexing makes the timing of all that challenging. Seems like this could also be a great programmatic solution for writing reliable tests.

I dont know if my work will help you since the idea is to say display codelens after the indexing is finished.

I think we were inspired by some code you wrote which subscribed to the message bus but looks like you already moved away from that.

When I have investigate how to know when index is finished I have found this https://github.com/JetBrains/intellij-community/blob/master/platform%2FtestFramework%2Fsrc%2Fcom%2Fintellij%2FtestFramework%2Ffixtures%2Fimpl%2FCodeInsightTestFixtureImpl.java#L338

Perhaps using this method or copy it in your code base could resolve your timing problem?

Thanks. @aparnamichael @turkeylurkey We should take a look at this.

[angelozerr]

@CppCXY @InSyncWithFoo @seachicken @KUGDev @AlexWeinstein92 @aparnamichael @MituuZ @turkeylurkey @mrglavas @koxudaxi @FalsePattern @onriv @kristofvb @themartdev @kdvolder please test my PR #570 which could have some impact.

The idea of this PR is to:

• don't start language server if one or several project are indexing. It means if a Project A is indexing, the Project B will not start the language server. It will wait for that indexing from all projects are finished. After spending a lot of time by starting IntelliJ with several projects which have several language servers and several editors,the language servers must be started only when indexing for ALL projects are finished otherwise, starting a lot of processes during any project indexing will freeze the IJ.
• when indexing will be finished, all opened editors will be refreshed with codelens, inlay hint and folding (document symbols, documentHyperlink will be lost for the moment, you will have too type a space to refresh the editor).

Please try this PR by installing the build zip (see instruction at https://github.com/redhat-developer/lsp4ij?tab=readme-ov-file#testing-the-ci-builds) andplease give me feedback, because I would like to really merge this PR which is very imptant to keep good performance when IJ is starting and in our case with IJ Quarkus to avoid having error like redhat-developer/intellij-quarkus#1373 or other like lossing some codelens, diagnostics in Java files.

So the change with this PR, no LSP features like codelens, completion, etc will not be available when IJ is indexing.

Thanks so much for your feedback!

[angelozerr]

@CppCXY @InSyncWithFoo @seachicken @KUGDev @AlexWeinstein92 @aparnamichael @MituuZ @turkeylurkey @mrglavas @koxudaxi @FalsePattern @onriv @kristofvb @themartdev @kdvolder I merged the PR after doind a lot of tests with IJ Quarkus, with other language servers and it seems it is working pretty well:

• when IJ is starting and does some scanning files, indexing..., no language servers are started. Performance are the same than without LSP4IJ. Please note that if you open several projects, language servers are started when indexing for all projects are finished (langaue server from a given projet doesn't start if an another project is scanning files)
• once scanning files indexing is finished, all language servers are started, didOpen are done for all opened files and codelens, inlay hints, folding are refreshed for all editors which are associated to a language servers. (documentLink, documentSymbol are not refreshed for the moment, you need to update editor content to refresh them)
• this refresh editor was an hard part because IJ doesn't provide some API to do refresh code vision, inlay hint, folding and classes which manages that are not the same from different version. I have tested with 2023.2 and 2024.3 and it is working pretty well.

I have used this refresh editor codelens, inlay hint also:

• to support LSP workspace/codeLens/refresh and workspace/inlayHint/refresh
• to remove codelens, inlayhint folding when language server is stopped (when all files are closed, or when you stop with menual context menu)
• to recalculate codelens, inlayhint folding when language server is started (with start action menu for instance).

Hope it will not have some trouble with your language servers, you can test this feature with https://github.com/redhat-developer/lsp4ij?tab=readme-ov-file#testing-nightly-builds

I need to fix some other issues but I would like to create ASAP a new release of LSP4IJ 0.8.0, so please give me feedback ASAP to fix some troubles before the release. Thanks!

[mrglavas]

@angelozerr I did some manual testing with your PR yesterday and did not encounter any problems with what I tried. We also ran our test automation: https://github.com/OpenLiberty/liberty-tools-intellij/actions/runs/11897921685/job/33153253651 against your PR and got good results on Linux and Windows. Our Mac builds often fail for other reasons. I haven't analyzed the logs, but suspect it's something unrelated to your changes in LSP4IJ.

[angelozerr]

@angelozerr I did some manual testing with your PR yesterday and did not encounter any problems with what I tried. We also ran our test automation: https://github.com/OpenLiberty/liberty-tools-intellij/actions/runs/11897921685/job/33153253651 against your PR and got good results on Linux and Windows. Our Mac builds often fail for other reasons. I haven't analyzed the logs, but suspect it's something unrelated to your changes in LSP4IJ.

Thats great thanks for your feedback. Hope you will see better performance and no errors when Java classes are visited to collect data with your IJ plugin.