Refresh Gradle Project performance on large multiproject

Help/Discuss Buildship
1

Hi,

I’m investigating in my eclipse performance problem using Buildship during Refresh Gradle Project.
I’d like to understand if me and my collages are following the best practice using Buildship.
In an old thread I read about sampling the eclipse performance during the refresh and I’d like to give some sampling to better understand things.
During the refresh the job in eclipse taking more time is “Synchronize Gradle projects with workspace” (pic above). This job seems to cycle through every single project of the root project.
I’m currently on Linux, with a jdk 11 and gradle 6.7.1 .
The performances are far way better than windows (thanks NTFS).
We have about 1000 subprojects and we only apply the necessary plugin to work with the IDE:

Main configuration

allprojects

subprojects Project:

  • java-library
  • eclipse-wtp

Here are some sampling, I’m not used to them so if you need some more actions or new profiling just tell me the right configuration you need.

This is and async profile
gradleRefreshAsync.zip (1.8 MB)
This is a full profile
gradleRefreshFull.zip (2.1 MB)

here the configuration

sampling_full_option
sampling_full_option864×575 20.4 KB

The long eclipse job is this one:
running_eclipse_job

Thanks in advance

EDIT:
I’m currently optimizing the use of ‘eclipse’ and ‘eclipse-wtp’ but I cannot see any improvements.

2

The largest chunk of the project sync is (or should be) the Gradle configuration. I’d first suggest comparing the Buildship sync time with the configuration phase of running gradle tasks on the command line.

  • If there is a large difference, then it’s an indication that Buildship does something ineffective.
  • If the difference is small then you should profile what happens in the configuration phase. There are several ways to profile the configuration phase, but the easiest is to use build scans
    (example).