Skip to content

Slow workspace initialization and reference search in large Gradle monorep #3904

New issue
New issue
Open
Open
Slow workspace initialization and reference search in large Gradle monorep#3904
Assignees
snjeza
Labels
regression

Description

@idandam
idandam
opened on Dec 25, 2024

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?

Activity

  1. snjeza commented on Dec 27, 2024

    @snjeza
    snjeza
    on Dec 27, 2024
    Collaborator

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

  2. snjeza
    self-assigned this
    on Dec 29, 2024
  3. snjeza
    added
    regression
    on Dec 29, 2024

  4. rgrunber commented on Jan 17, 2025

    @rgrunber
    rgrunber
    on Jan 17, 2025
    Member

    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.

  5. idandam commented on Jan 18, 2025

    @idandam
    idandam
    on Jan 18, 2025
    Author

    @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.

  6. snjeza commented on Jan 18, 2025

    @snjeza
    snjeza
    on Jan 18, 2025
    Collaborator

    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 #3917 (comment)

    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 #2537 for example.

  7. idandam commented on Jan 20, 2025

    @idandam
    idandam
    on Jan 20, 2025
    Author

    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.

  8. idandam commented on Jan 20, 2025

    @idandam
    idandam
    on Jan 20, 2025
    Author

    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.

  9. snjeza commented on Jan 20, 2025

    @snjeza
    snjeza
    on Jan 20, 2025
    Collaborator

    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?

  10. joyous-coder commented on Feb 8, 2025

    @joyous-coder
    joyous-coder
    on Feb 8, 2025

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

  11. guoai2015 commented on Feb 14, 2025

    @guoai2015
    guoai2015
    on Feb 14, 2025

    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.

  12. snjeza commented on Feb 15, 2025

    @snjeza
    snjeza
    on Feb 15, 2025
    Collaborator

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

  13. qomosoloto commented on Feb 21, 2025

    @qomosoloto
    qomosoloto
    on Feb 21, 2025

    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%

  14. guoai2015 commented on Feb 24, 2025

    @guoai2015
    guoai2015
    on Feb 24, 2025

    @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

  15. snjeza commented on Feb 25, 2025

    @snjeza
    snjeza
    on Feb 25, 2025
    Collaborator

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

  16. rgrunber commented on Mar 13, 2025

    @rgrunber
    rgrunber
    on Mar 13, 2025
    Member

    @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.

  17. einarjohnson commented on Apr 19, 2026

    @einarjohnson
    einarjohnson
    on Apr 19, 2026

    @rgrunber , was this fix merged you mention in the comment here above?

  18. rgrunber commented on Apr 20, 2026

    @rgrunber
    rgrunber
    on Apr 20, 2026
    Member

    Yes, it is referenced above my other comment : microsoft/vscode-gradle#1649 (although wasn't referenced in the issue I linked).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

regression

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions