Hey folks, I’m seeing pathologically slow build speeds with certain JDK versions, whereas other versions are blazing fast. Instead of just shrugging and running with a ‘fast’ JDK, I thought I’d seek some advice on how to troubleshoot the issue.
I’m running OS X 10.11.3, with Gradle 2.10 installed via homebrew. Gradle is configured with “org.gradle.daemon=true” in ~/.gradle/gradle.properties, but otherwise running defaults (which gives the gradle daemon -Xmx1024m). The project is an enterprise Java mudball with 11 submodules.
The timings below are from spawning fresh daemons doing “gradle clean build”:
1.8.0_72, x86_64 - Total time: 4 mins 55.025 secs
1.8.0_40, x86_64 - Total time: 15.146 secs
1.7.0_80, x86_64 - Total time: 21.548 secs
1.7.0_75, x86_64 - Total time: 5 mins 1.711 secs
Warmed-up daemons and incremental builds aren’t a lot faster for the pathological builds - when running with --profile, the Dependency Resolution tab shows that each of the 28 compile/provided/runtime/providedRuntime/earlib (et cetera) dependency tasks take 10.0xx seconds. This smells a lot like network timeouts, and other threads about slow dependency resolving have mentioned broken repositories as an error source. However, running with ‘–offline’ results in the same build speed.
So, any good ideas on how to proceed troubleshooting would be appreciated
Oh, I didn’t realize you were supposed to do either of those - I did stop daemons at one point, though, which didn’t help.
I’ve just stopped the daemons and cleared caches, and currently doing a clean build with JDK 1.8.0_72. It seems I’m getting the ~10sec delay for each “Resolving dependencies” step, but the process of downloading dependencies seems to be fast and without any hiccups.
I’ve just done another clean build with 1.8.0_40 (after stopping daemons, verified no other Java processes were running, and rm’ing the cache), which resulted in 27.7sec build speed (we have a local Nexus mirror, so downloads are fast).
My guess is that it’s caused by authentication with the nexus repository. If gradle gets a 401 authentication challenge response it will attempt authentication using all schemes supported by Apache HttpClient
You might want to explicitly configure preemptive authentication
I’ll look into that - I would have expected that Gradle doesn’t try to reach out (and thus not do any authentication) when running with –offline, though?