Refresh Gradle Project performance on large multiproject


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


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 (1.8 MB)
This is a full profile (2.1 MB)

here the configuration

The long eclipse job is this one:

Thanks in advance

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

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