Performance issue when enabling Build Server

[jdneo]

See: redhat-developer/vscode-java#3357

          Wow, so slowly. I have to wait 30 minutes after opening the project for it to run. I don't know the cause yet, I hope the development team soon finds the cause.

Originally posted by @alexanderloong in redhat-developer/vscode-java#3357 (comment)

[jdneo]

One thing we can explore is to avoid Gradle building the workspace right after import. Instead, let it build before launch/test

[alexanderloong]

Thanks, my problem has been resolved. People can go into setting and choose it.

[mbruce]

This is still the #1 issue with this plugin. I have a project I can open in IntelliJ in a few minutes. But it's over an hour every time in vscode. It's completely unusable.

[Yazington]

2024 and this is still an issue

[mbruce]

2024 and this is still an issue

Yep, still terribly slow.

[mbruce]

Keeping this alive. Still terribly slow.

[jdneo]

@mbruce Have you tried the pre-release version?

[mbruce]

yes, confirmed just now that it's still extremely slow with the prerelease. over an hour and it's still initializing. this will eventually complete.

[jdneo]

@mbruce Could you share the server log? Run Java: Open Java Language Server Log File

[devondragon]

log.txt

@jdneo - I'm having the same issue and here is my log file while it's slowly loading

[devondragon]

FWIW I am not having this issue with VS Code Insiders, just the main VS Code release version.

[jdneo]

FWIW I am not having this issue with VS Code Insiders, just the main VS Code release version.

@devondragon I'm shocked that they perf can be different between vscode release and insiders. Is there any setup difference between two? For example, different extensions are installed?

[rgrunber]

in vscode-java, there are setting that are set to auto, which means disabled by default in VS Code, but enabled in VS Code Insiders (they're experimental settings we wish to enable by default eventually) !

I was just investigating redhat-developer/vscode-java#3904 and one odd behaviour I ran into was that if "Gradle for Java" was installed, after the first "Java: Clean Language Server Workspace" command, all other reloads of the window caused the index to be rebuilt every time. The project itself was Maven and unrelated to Gradle. Either way this shouldn't happen as nothing has changed. At first I never ran into this because I always ran with java.sharedIndexes.enabled": "on", but this setting has an auto value which means it behaves differently in the Insiders release.

@devondragon , does setting java.sharedIndexes.enabled": "on" improve performance for you ? There's still probably something else going on because I the build finishes every time but worth a try.

[devondragon]

That seems to improve things considerably! Thanks!!

[rgrunber]

I think I found another problem. Probably the root one.

vscode-gradle/extension/jdtls.ext/com.microsoft.gradle.bs.importer/src/com/microsoft/java/builder/BuildStateManager.java

Line 73 in 86a76e9

ResourcesPlugin.getWorkspace().addSaveParticipant(JavaCore.PLUGIN_ID, this);

vscode-gradle is contributing a participant under the id org.eclipse.jdt.core. But jdt.core has its own participant that you're kicking out 😛 . See https://github.com/eclipse-jdt/eclipse.jdt.core/blob/4d5b78631454da002130f609615dcca34b635574/org.eclipse.jdt.core/model/org/eclipse/jdt/internal/core/JavaModelManager.java#L5448. So what does the jdt.core participant do ? Oh not much, just making sure the external library timestamps get saved correctly : https://github.com/eclipse-jdt/eclipse.jdt.core/blob/4d5b78631454da002130f609615dcca34b635574/org.eclipse.jdt.core/model/org/eclipse/jdt/internal/core/JavaModelManager.java#L4709 ➡ https://github.com/eclipse-jdt/eclipse.jdt.core/blob/master/org.eclipse.jdt.core/model/org/eclipse/jdt/internal/core/JavaModelManager.java#L4797-L4798 . Without that they aren't saved, and later on we re-index the library because the old timetsamp is nowhere to be found, but the new one exists : https://github.com/eclipse-jdt/eclipse.jdt.core/blob/4d5b78631454da002130f609615dcca34b635574/org.eclipse.jdt.core/model/org/eclipse/jdt/internal/core/DeltaProcessor.java#L1067-L1069 . Luckily this seems like an easy fix.

(Oh, and disabling vscode-gradle isn't enough to make the problem go away because we use extensions.all when collecting contributions on the vscode-java side, and that doesn't seem to exclude disabled/uninstalled extensions)

[mbruce]

no luck for me with that setting. still takes forever to index, and sits on 32% for at least an hour.