Slow workspace initialization and reference search in large Gradle monorep

[idandam]

Description

Each time I start VSCode, the Java Language Server re-initializes the workspace which takes a considerable amount of time. During this initialization period, I cannot:

• Navigate to object references
• See method callers/usages
• Use other indexing-dependent features

Even after indexing is complete, searching for references takes several seconds to display results, which is significantly slower compared to IntelliJ.

Project Structure

• Type: Monorepo with root project and multiple modules
• Build Tool: Gradle

Current Setup

• Extensions installed:
  • Gradle for Java
  • Java Language Server

What I've tried

• Setting "java.import.gradle.enabled": false - This didn't help as it prevented project importing altogether, making indexing features unavailable
• Default settings with "java.import.gradle.enabled": true - Works but very slow initialization

Expected Behavior

• Faster workspace initialization on startup
• Quick reference search response (similar to IntelliJ performance)
• Persistence of indexing between editor sessions

Actual Behavior

1. Every editor restart triggers full workspace reinitialization
2. Reference search takes several seconds to display results
3. Unable to use navigation features during initialization

Environment

• OS: macOS Ventura 13.1
• Java Language Server Extension Version: 1.38.0
• Gradle for Java Extension Version: 3.16.4
• VSCoder Version: 1.93.1
• JDK Version: Amazon Coretto 1.8

Additional Context

This is affecting development productivity significantly, especially when working with large codebases that require frequent navigation between references and implementations.

Question

Is there a way to:

1. Persist the indexing between editor sessions?
2. Optimize the reference search performance?
3. Configure selective indexing for specific modules while maintaining full functionality?

[snjeza]

@idandam Could you, please, try VS Code 1.40.0 ?

[rgrunber]

It would be good if @idandam could let us know if this improves the situation (fix is in the vscode-java pre-release builds, or by trying the vsix referenced above). The only thing I could confirm is that this eliminates some possible deadlocks.

[idandam]

@snjeza @rgrunber can't confirm i see an improvement with the attached vsix after installing it.

opening the java projects takes almost 5-8 minutes, event if only existing and entering vscode.

slow references - see specific methods references is slow (approx 30 seconds to find 16 references that calls a specific method)

i have about 40 modules, each containing a gradle build configuration. All contained inside the root project with the main gradle build configuration. Is there a way to tell java language server to ignore a subset of modules for better performance ?, I can exclude modules in gradle since i could not find any working solutions (exclusion of modules) using any of the properties the java language server provides.

[snjeza]

can't confirm i see an improvement with the attached vsix after installing it.

@idandam You can use VS Code pre-release.

opening the java projects takes almost 5-8 minutes, event if only existing and entering vscode.

Could you try the steps at https://github.com/redhat-developer/vscode-java/issues/3917#issuecomment-2598649255

i have about 40 modules, each containing a gradle build configuration. All contained inside the root project with the main gradle build configuration. Is there a way to tell java language server to ignore a subset of modules for better performance ?, I can exclude modules in gradle since i could not find any working solutions (exclusion of modules) using any of the properties the java language server provides.

You can use "java.import.exclusions". See https://github.com/redhat-developer/vscode-java/issues/2537 for example.

[idandam]

Could you try the steps at #3917 (comment)

i will try and update

You can use "java.import.exclusions". See #2537 for example.

i've tried that multiple times and played with it. this never works.

[idandam]

tried the pre-release.

same behavior with respect to performance related to my use cases.

aprox 15 minutes to finish open java projects, after initializing workspace, building, compiling, analyzing ,etc.., this also occurs after exiting vscode and then re-entering. method's references take a lot of time to evaluate.

"java.import.exclusions" not doing any effect also #3917 comments did not help here.

[snjeza]

this also occurs after exiting vscode and then re-entering.

Reloading a project that has been built correctly should be much faster.

i've tried that multiple times and played with it. this never works.

Could you provide a project example reproducing the error?

[joyous-coder]

Indexing jars and all kinds of files makes it quite slow I suppose.

[guoai2015]

What I want to say is that this problem is not only with Gradle-based projects, but also with Maven-based projects. It's a terrible experience every time VSCode reinitializes the workspace upon startup. Moreover, with each new version, it gets slower and slower, frequently freezing. It either freezes during the "Searching" phase or during the "Publish Diagnostics" phase. As a result, my colleagues look down on me for using VSCode to develop Java projects.

[snjeza]

@guoai2015 What version of VS Code are you using? Could you provide a project example reproducing the error?

[qomosoloto]

What I want to say is that this problem is not only with Gradle-based projects, but also with Maven-based projects. It's a terrible experience every time VSCode reinitializes the workspace upon startup. Moreover, with each new version, it gets slower and slower, frequently freezing. It either freezes during the "Searching" phase or during the "Publish Diagnostics" phase. As a result, my colleagues look down on me for using VSCode to develop Java projects.

Yes, It's a terrible experience. It just stopped here .... Searching.....

00f8a868 LookupJDKToolchainsJob [Done]
37190b5e Resolve plugin dependency [Done]
103c2f0c Reporting encoding changes. [Done]
ad7f5a35 Send Classpath Notifications [Done]
1721f7df Refreshing workspace [Done]
f0fa1207 Building [Done]
5b3c4f08 Building [Done]
ece7c171 Building [Done]
0bbe2fea Searching... - 0% 

[guoai2015]

@guoai2015 What version of VS Code are you using? Could you provide a project example reproducing the error?

@snjeza VS Code version：1.97.2 Language Support for Java(TM) by Red Hat version：1.39.0

The failure is exactly the same as @qomosoloto

I had no choice but to switch to the previous version 1.38.0

[snjeza]

@guoai2015 I can't reproduce the issue. Could you show your extensions?

[rgrunber]

@idandam

• Does the situation improve if you increase maximum heap size (Xmx) with "java.jdt.ls.vmargs": "-XX:+UseParallelGC -XX:GCTimeRatio=4 -XX:AdaptiveSizePolicyWeight=90 -Dsun.zip.disableMemoryMapping=true -Xmx4G -Xms100m -Xlog:disable" ? The default value is the same thing but with XmX1G.
• You can reduce the time taken to index libraries (required for things like searching) by setting "java.sharedIndexes.enabled": "on". This will save all index files in a common location on the machine. Default locations are :

Windows: First use $APPDATA\\.jdt\\index, or ~\\.jdt\\index if it does not exist macOS: ~/Library/Caches/.jdt/index Linux: First use $XDG_CACHE_HOME/.jdt/index, or ~/.cache/.jdt/index if it does not exist

• There was a recent bug discovered in vscode-gradle that caused the index to always rebuild, that would have slowed the time required prior to being able to do searches. The fix has been merged, but I'm still waiting for a release of the extension. It may also improve things.