10 seconds is quite a lot. Of course it depends on the machine you’re working on. You’re right, a lot of time ist spend on startup. One thing I recommend you is to use the gradle daemon to get a better user experience when working with gradle in the terminal. See the gradle userguide (chapter 19) for details:
It may not be related to your problem but, I’ve encountered a problem on a Windows PC where Gradle took too much time to exec trivial tasks (even a simple ‘gradle -version’ took 2 secondes)
Actually it was related to a bogus internet proxy configuration (don’t ask me why). When the proxy was properly configured it went back to usual exec time. It seems that even for a ‘gradle -version’ gradle (or the JVM) is sensitive to a misconfigured network layer.
Yes, network timeouts/misconfiguration are among the suspects. Is there a way to check whether that’s the problem? Something like “gradle -Dreport_network_timeouts” would be easiest for me Alternatively, I could start checking whether a proxy might be configured, but I wouldn’t know where to look because I haven’t touched any networking configuration on my machine in years.
You can try running Gradle using ‘"–offline"’ flag. Every time I had a slow startup it was related to a networking problem, especially when applying scripts from GitHub (it can be slow at times).
Is this native Linux, or is it something like cygwin or similar? Is there a network file system involved (e.g. for user home)? Also try to raise memory limits (e.g. ‘export GRADLE_OPTS=-Xmx512m’).
The effect of changed GRADLE_OPTS was: First run had continuous disk activity (probably because I reactivated .m2) and 13.5 sec. Subsequent runs had no disk activity and took between 9.7 and 9.9 seconds. Which is just measurably better than the 10.x seconds I had before.
Changing to 1024m didn’t cause disk activity anymore, and gave me the same timings.
Have you experienced slow performance for other Java-based apps as well? Any virtualization or cygwin involved? Can you try to update to latest Java 7 update? Do you have a slow/full disk?
Java stuff feels somewhat sluggish on my machine. OTOH I’ve always been attributing that to the usual warmup issues in Openjdk, compiling ~100kloc Java libraries inside a Maven build takes less than a minute.
No virtualization, no cygwin. Just a standard Ubuntu box.
Java upgrading would be somewhat inconvenient because it’s managed by the package manager. Here’s what I have:
OpenJDK 64-Bit Server VM (build 23.2-b09, mixed mode)
u9 is somewhat old but then again, Eclipse and Maven haven’t shown any obvious performance problems. I do have a java 6 installed. It shouldn’t be involved unless gradle is doing something funky when starting new JVMs.
I have an encrypted home directory. Disk issues are at the low end of the suspects list for me. atop reports 7.8G RAM, 1.4G free (i.e. never used, not even for cache which is 4.4G).
Can you point ‘GRADLE_USER_HOME’ to somewhere else, to rule out that encryption is to blame (at least partially)? Same for the Gradle distribution and the build’s working directory.
–profile results (sorry I don’t know how to convert html to markdown):
Summary Description Duration Total Build Time 9.821s Startup 4.988s Settings and BuildSrc 2.272s Loading Projects 0.449s Configuring Projects 1.738s Task Execution 0.202s Configuration Project Duration All projects 0.776s : 0.776s Dependency Resolution Dependencies Duration All dependencies 0.043s classpath 0.040s :classpath 0.003s Task Execution Task Duration Result Project : 0.202s (total) :hello 0.202s
Running from an unencrypted directory didn’t change the timing. (I removed the executable flags from any gradle-related scripts in my normal home directory to make 100% sure that it was the copy on the unencrypted directory that was run.)
Would it make sense to pull the Gradle sources into Eclipse and get it running? I have: * plenty of experience developing Java inside Eclipse * zero Groovy knowledge (but enough Lisp and Haskell background to understand FPL) * zero Osgi experience (so no Eclipse plugin hacking). If it’s a download, a Project Import (Maven or standard) inside Eclipse, and a debug configuration with a current directory and a set of command line parameters, I can try that on the spot.
… unless Gradle is really taxing CPU or RAM resources.