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.

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.

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).

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.