Very slow in large multi-projects

[abrolle]

I am working on a project with 500+ eclipse projects. The eclipse-integration-gradle plugin runs ok on version 2.9.1.xx-201408111402-e44. I have tried different later versions but all are getting extremely slow, both import and refresh of gradle tasks. Latest version from http://dist.springsource.com/snapshot/TOOLS/gradle/nightly tried today.
Running on eclipse 4.4.0 using gradle 2.2.1.

[andrask]

👍 with 300+ projects

Additionally, almost every time I update the code, many eclipse projects fall apart: lose gradle nature, get inexplicable compilation errors, lose previously known source folders... Practically, the only solution is to reimport everything which is a huge pain.

I'm trying to put together an example project. One of the major issues seems to be when an already imported module is deleted.

[kdvolder]

I'm trying to put together an example project

Great, a sample would help a lot, otherwise I wouldn't know where to start debugging it.

[abrolle]

I'll provide you with profiling results tomorrow. Evaluating 500+ projects has gone from seconds to minutes from the 2.9.1.xx-201408111402-e44 and now. I ran JMC Java Flight Recorder and most time was spend in hash maps. Will get back with details.

[kdvolder]

Are these projects part of a single multi-project build? Or separate
projects (or something in between).

Have you tried mucking around with some of the new options
to remap project/jar dependencies. Maybe the model builds required for
these options are slowing your stuff down. disabling some of these options
may help (especially if you do not really want to use them in the first
place).

My suspicion is that model builds take more time because, unfortunately we
are not able to take advantage of building many models in a single tooling
API request so you get to build many small models which is much slower than
building one big model. If so, there's not much can be done. See discussion
here:
http://forums.gradle.org/gradle/topics/gradle-eclipseproject-and-buildinvocations-model-for-the-same-project-have-different-tasks-for-projects

At/near the end of the thread...

We should really use 'BuildActions' to build all these 'little models' at
once, but a bug in tooling-api makes this impossible in OSGI environment
except for Gradle 2.3 or above.

On Tue, Feb 10, 2015 at 12:15 PM, abrolle notifications@github.com wrote:

I'll provide you with profiling results tomorrow. Evaluating 500+ projects
has gone from seconds to minutes from the 2.9.1.xx-201408111402-e44 and
now. I ran JMC Java Flight Recorder and most time was spend in hash maps.
Will get back with details.

—
Reply to this email directly or view it on GitHub
#82 (comment)
.

[abrolle]

All projects are part of the same multi-project build. No maven or other jar repo dependencies, only pure project dependecies.
I have tried disabling all the new options relating to dependecy management.
The Gradle 2.3 release is near. Are you planning to update to this soon?

Below are a few screen shots from JMC Flight Recorder:

[abrolle]

I read the discussion you refered to on gradle forums. I would be great to introduce the 'BuildActions' approach. However my 500+ projects work fine with the 2.9.1.xx-201408111402-e44 version. Something must have been done between then and now to make it much slower.

[kdvolder]

Something must have been done between then and now to make it much slower.

Indeed, before we only used 'EclipseProject' model from Gradle and this can be built for all projects in a multiproject in one go.

In current version of Gradle there are also some other models being used which, unfortunately don't allow this kind of 'bulk' building of models. I am almost certain this has something to do with your slow down where you are now hvaing to build '500 little models' instead of a single big one.

Some of these changes can be disabled in the preferences which I asked you to try.

But I think there are some changes also in the task models which can not be disabled. They were introduced to allow for identification of public tasks and fix some problems with the task models.

You could try doing an import of your projects and disabling any execution of tasks during the import, it may be your projects then do not import correctly, but it might reveal if building the tasks models is what's slowing things down.

[kdvolder]

The Gradle 2.3 release is near. Are you planning to update to this soon?

When it comes out we will probably update to its tooling API, but it doesn't help with the BuildActions issue since the problem is not in the tooling API itself but in the Gradle version that people use.

This means we still cannot use BuildActions until everyone has switched to Gradle 2.3.

[BoykoAlex]

Did you have Gradle Tasks view opened? Did you use Quick Tasks Launcher or “Gradle Build” external tools launch config wizard?
Try closing Gradle Tasks view and not using the Quick Tasks Launcher and see if that helps.
Once you closed Gradle Tasks view try re-importing the project…

Now, I’ve noticed that you’re talking about "importing and refreshing gradle tasks”… Gradle tasks can be refreshed in the Gradle Tasks view. Only Gradle projects can be imported though… My guess it’s the project import/refresh being slow, correct? Is that annoying because the UI is blocked at that time?

On Feb 12, 2015, at 12:00, Kris De Volder notifications@github.com wrote:

The Gradle 2.3 release is near. Are you planning to update to this soon?

When it comes out we will probably update to its tooling API, but it doesn't help with the BuildActions issue since the problem is not in the tooling API itself but in the Gradle version that people use.

This means we still cannot use BuildActions until everyone has switched to Gradle 2.3.

—
Reply to this email directly or view it on GitHub #82 (comment).

[abrolle]

I ran the import again with the 'Gradle Tasks View' closed. This made the import go quicker.
Also having the 'Gradle Tasks View' closed when woring in eclipse made things quicker.
I also seems quicker to find tasks in the 'quick launcher' than refreshing the 'gradle tasks view'

The external tools launch config wizard is not something we use. We have so many projects and mapping specific gradle tasks with this one would take quite some time. The normal java projects have no specific tasks. For applications we have specific packaging and install tasks we want to execute.

I should have been clearer in my desciption. Meant: "Importing projects" and "Refreshing tasks in the gradle tasks view".

The problem with import being slow is the we are not working in a fixed project structure. New projects are added and dependencies are changed. When 10+ projects have updated dependencies the normal approach has been to reimport the projects again. This takes time. Do you have a better suggestion on how to approach this situation?

[kdvolder]

Sounds like the changes in how task models are computed are responsible for your troubles.

I also seems quicker to find tasks in the 'quick launcher' than refreshing the 'gradle tasks view'

Alex would know this better than me, maybe the quicklauncher builds different (old-style) task model so is not affected by the slow down.

Do you have a better suggestion on how to approach this situation?

Selecting all the projects and doing 'Refresh All' or 'Refresh Dependencies' might work better, but I suspect it will be prone to the same problem. Plus that might not be as convenient if new projects have been added.

[kdvolder]

Thinking some more about what might be going on. So... having tasks view open slows down import.

Probably its the 'many little model builds' the task viewer creates to build task models are holding up the model builds required for importing project.

Effectively only one model can be 'building' at the same time.

If task models are building for several minutes (not too surprising if there's 100s of them to build) then it would delay the model builds for import.

[BoykoAlex]

I have tried Spring-XD code base: https://github.com/spring-projects/spring-xd with STS 3.6.3 (Gradle 3.6.3) and STS 3.6.0 (Gradle 3.6.0).
I didn't notice a slow down (at least significant one) when Gradle Tasks view is opened. The only difference between 3.6.3 and 3.6.0 was when switching between projects in Gradle Tasks view. Switching to a project that has no cached BuildInvocations model cached causes the BuildInvocations model to build first before the tasks are shown (takes ~5 sec with Spring-XD workspace, this is expected). Also, when Gradle Tasks view is refreshed the EclipseProject model is build for the hierarchy of projects and one BuildInvocations model is built for the currently selected project. Note that BuildInvocations models are cached for projects, consequently it won't be build again for the project if it's selected again.
Wonder if you can try Spring-XD code base and point exactly to a place, process that runs slower.

[abrolle]

I will try this. Is there any chance the slowdown I'm seeing is caused by the fact that we are applying the eclipse plugin to each subproject? We are using this to assign each subproject a unique name: group + '.' + name.

[jonathannaguin]

I am experiencing the same issue.
I have a multi-project setup with 125 projects.
At start up I can see, in the progress view, that every sub-project has a task for "fetch model of type stseclipseproject". The time it takes to finish all the tasks is more or less 15 minutes.
Also, when I select the option to Refresh Dependencies for one project it takes also a lot of time, approximately 5 minutes or so.
I am using Eclipse 4.4.2 and Gradle IDE 3.6.4.201503050952-RELEASE.

---

I have only enabled the Use Custom Tooling Model preference.

[kdvolder]

Disable the custom tooling model and the problem should be solved. This is a known issue and there's nothing we can do about it. There is a more efficient way of building the model but unfortunately a bug in Gradle prevents us from using it as it doesn't work in OSGI environment.

[kdvolder]

Also, I beleave that, being aware of how long it takes to refresh these models, I did my best to implement the refresh in such a way that it all happens in a background and shouldn't block you from continuing to work.

[jonathannaguin]

@kdvolder Thank you for your quick response!

Do we have an estimation of when the bug in Gradle will be fixed? It it registered in the issues tracker?
Basically, I have enabled the tooling because I was having issues excluding transitive dependencies between projects and I took the solution answered here. I might need to tackle this issue in a different way then...

[kdvolder]

The bug is fixed in the Gradle version 2.3. However, the problem is this that we still can't practically use it because, if we do, then we must either:

• limit all users of the tools to move on to Gradle 2.3.
• implement different ways of building model depending on the version of Gradle the user is using.

Neither of these are good options for us as the former is not reasonable to many users and the latter is a maintenance nightmare for us.

So, this means we are stuck with this implementation until Gradle 2.2 no longer matters to most users.

The discussion is here:
https://discuss.gradle.org/t/gradle-eclipseproject-and-buildinvocations-model-for-the-same-project-have-different-tasks-for-projects/2529/20