We have a very large system that takes a long time to build and I was eager to try out gradle 2.4 for its performance improvements. Unfortunately, I’m not seeing any improvements. In fact, it’s slower in some cases than gradle 2.2 (what we’re currently using). I compared two types of builds: one from scratch (after doing a clean) and one after a complete build where nothing needs to be done (no-op). Here’s my times in mm:ss:
2.2
from clean build: 12.27
no-op build: 2:44
2.4
from clean build: 14:11
no-op build: 2:42
I also tried the latest nightly build of 2.5 and I get similar results to 2.4 except its no-op was 15 seconds slower. Any thoughts?
Are you running with any special JAVA_OPTS, GRADLE_OPTS, etc?
Do you have the daemon turned on?
Can you re-run your 2.4 builds with --profile and post a link to the report (build/reports/profile*)? If you don’t want it to be public, you can email me at sterling.greene ‘at’ gradleware.com with the report.
I don’t doubt there are improvements. Just trying to find out what we’re doing so that we don’t see them.
We do have some custom JAVA_OPTS. We’re setting Xmx to 384m, setting -Djava.ext.dirs to some extra jars and lastly -XX:-UseSerialGC -XX:-UseGCOverheadLimit. No GRADLE_OPTS.
I didn’t explicitly enable or disable the daemon. The release notes said no action was required. I did run each build twice.
I’ll email you a profile report.
That’s some imprecise wording on my behalf. What I meant was that there’s no changes required to make the daemon use these new capabilities. That is, you have to have already enabled the daemon.
Ran the ‘no-op’ build with --daemon, Xmx at 2048m. It dropped to 2:25 from 2:42. I ran it around 10 times, same result. Oddly, however, the first time I ran it this morning, it took a whopping 7:52. The subsequent run went back to around 2:25.
You might execute some expensive operation during the configuration phase that might or might not be aware of? Do you have any custom logic in place that is executed every time you run the build?
Ok. This is disturbing. I’ve been running these builds many, many times over the last week (5 to 10 times each day). Same results every time. I’ve been periodically switching between 2.2 and 2.4 (running several builds with each version between switching) with consistent results (2.4 slightly slower). However, all of a sudden this morning, I’m now getting results with 2.4 inline with 2.2. I’m confused why this suddenly changed. Does the daemon do some type of advanced learning, caching those results where a clean doesn’t affect it? Since I was getting such consistent results I didn’t get others to try this out. That’s my next step.
By the way, it appears that my first build of the day is still always around 8 minutes with gradle 2.4. I leave my machine on all night and don’t do any intensive work while a build is occurring. There’s a possibility our virus scanning software might be doing extra work or some other IT issue. I need to investigate that further, but I’m suspecting it’s not gradle unless the daemon is clearing it’s cache or something similar. Unfortunately, I only get one attempt per day to investigate.
To answer the other questions:
I’m running Java 8 on Windows 7. All files are local on a single SSD.
Our build has around 80 sub projects and contains around 13,000 java files, 21,000 total files (html, jsp, javascript, xml, other resources).
I don’t think my JConsole results would be useful since I captured it when it was executing faster.
To Benjamin’s point: We have lots of custom logic that is executed each time the build is run.