It's probably been at least a month (maybe more?) since I've done much
solr compilation, but today when I tried to test out a trivial local patch
(for SOLR-16241) I'm finding that compiling with gradle is obscenely
slow...
After explicitly removing my ~/.gradle/gradle.properties (in case it
wasn't playing nice w/some recent changes) i tried the following against
main/HEAD (using OpenJDK 11.0.4) ...
$ git clean -fxd && ./gradlew tasks && ./gradlew compileTestJava
The first gradlew command (to force it to download a fresh
gradle-wrapper.jar and run ':localSettings' only took 21s -- but the
second invocation (to pick up the local settings in a new daemon) took
"19m 31s" ! (note that's just compilation - not running any tests)
My CPU never got above 15%, and looking at occasional jstack dumps seemed
to show it always deep in errorprone classes. (Which i know isn't a new
thing in our build, and hasn't been upgraded since the last time i'm 100%
confident I ran the build to commit a bug fix)
When I hacked ./gradle/validation/error-prone.gradle to hardcode 'def
skipErrorProne = true' the entire "git clean -fxd ... && ./gradlew
compileTestJava" command started taking ~1 minute.
Jenkins builds don't seem to be this slow; which at first I assumed was
because error-prone.gradle ties skipErrorProne to rootProject.usesAltJvm
... but I don't see the WARN message from alternative-jdk-support.gradle
in any of the jenkins logs to suggest that they are being run in a way to
leverage the usesAltJvm support.
Has anyone else seen ridiculously long compilation times like this?
-Hoss
http://www.lucidworks.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@solr.apache.org
For additional commands, e-mail: dev-h...@solr.apache.org
