You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
For large multi-project builds, a Gradle Refresh operation takes a significant amount of time when there are many files in the project directories.
Most of the time is not spent on Gradle generating the .project/.classpath files, but on Eclipse refreshing the project afterwards.
This is an IO-bound operation which could be parallelized using multiple worker threads.
Expected Behavior
When performing a Gradle Refresh, after the Eclipse-specific files have been generated/updated, Eclipse should refresh the affected projects in parallel with multiple worder threads instead of only one as it currently does.
It would be even better to only refresh relevant files, but I don't know/think that is possible.
Context
In our multi-project build, we have some projects which create FatJARs containing over 10 000 classes from different JARs. When building these projects, all JARs are expanded into build/tmp, so there are many files in these directories.
A Gradle Refresh operation in Eclipse can take up to 5 minutes (only 15s are spent by Gradle generating the files, the rest is only Eclipse refreshing the projects), depending on the SSD type and virus scanner configuration, because Eclipse seems to scan all files in all project directories (even the Gradle build directory and there even the tmp directory).
If the 500+ projects would be refreshed in parallel by, say, 8 worker thread, this would reduce the refresh time enormously.
The text was updated successfully, but these errors were encountered:
For large multi-project builds, a Gradle Refresh operation takes a significant amount of time when there are many files in the project directories.
Most of the time is not spent on Gradle generating the .project/.classpath files, but on Eclipse refreshing the project afterwards.
This is an IO-bound operation which could be parallelized using multiple worker threads.
Expected Behavior
When performing a Gradle Refresh, after the Eclipse-specific files have been generated/updated, Eclipse should refresh the affected projects in parallel with multiple worder threads instead of only one as it currently does.
It would be even better to only refresh relevant files, but I don't know/think that is possible.
Context
In our multi-project build, we have some projects which create FatJARs containing over 10 000 classes from different JARs. When building these projects, all JARs are expanded into build/tmp, so there are many files in these directories.
A Gradle Refresh operation in Eclipse can take up to 5 minutes (only 15s are spent by Gradle generating the files, the rest is only Eclipse refreshing the projects), depending on the SSD type and virus scanner configuration, because Eclipse seems to scan all files in all project directories (even the Gradle build directory and there even the tmp directory).
If the 500+ projects would be refreshed in parallel by, say, 8 worker thread, this would reduce the refresh time enormously.
The text was updated successfully, but these errors were encountered: