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:
from clean build: 12.27
no-op build: 2:44
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.
Please also run it multiple times with the daemon turned on to get into a fully optimized state.
Besides our own benchmarks we heard from many medium and large projects in the wild that they had significant performance improvements.
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.
If this discussion continues offline, could you please post a summary of the conclusions here?
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.
Could you try setting -Xmx to 2048m and re-running with --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.
Have you been able to reproduce the 7:52 outlier?
Yes. I’ve had it happen twice now. Both times it was the first build of the day with the daemon.
What’s your environment like? OS, Java version, etc.
Is your project directory, cache directory (GRADLE_USER_HOME) or project cache directory (.gradle) on a network file system?
How large is your project (how many source files)?
While the build is running, could you open up jconsole and see if there’s anything strange (GC pauses, memory pressure, etc)?
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.
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.
Next time, you may add
--profile to the options and check the report in the root project build dir.