Trivial build takes 10 seconds - is this normal?


(toolforger) #1

Just started working through the user guide Found that the “hello” script takes 10 seconds to run, 3-4 of which seem to be startup.

Some timings:

$ time gradle -v


Gradle 1.4


Gradle build time: Montag, 28. Januar 2013 03:42 Uhr UTC

Groovy: 1.8.6

Ant: Apache Ant™ version 1.8.4 compiled on May 22 2012

Ivy: 2.2.0

JVM: 1.7.0_09 (Oracle Corporation 23.2-b09)

OS: Linux 3.2.0-37-generic amd64

real

0m3.685s

user

0m4.676s

sys

0m0.312s

$ time gradle hello

:hello

Hello world!

BUILD SUCCESSFUL

Total time: 10.078 secs

real

0m10.455s

user

0m15.793s

sys

0m0.524s


(René Groeschke) #2

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:

http://gradle.org/docs/current/userguide/gradle_daemon.html#enter_the_daemon

cheers, René


(toolforger) #3

4/8-core i7 CPU, 8 Gigs of RAM. I suppose that that should be enough :slight_smile: … unless Gradle is really taxing CPU or RAM resources.

The daemon didn’t improve speed, the times vary by less than 10%.

Where should I look next? I could post a debug log if that helps. The log for -v is about 20 lines, the “hello” one would be around 100 lines I think.


(Stephane Galles) #4

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.


(toolforger) #5

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 :slight_smile: 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.


(Evgeny Goldin) #6

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


(toolforger) #7

Good idea with --offline. Didn’t change the timings, unfortunately:

$ time gradle -v


Gradle 1.4


Gradle build time: Montag, 28. Januar 2013 03:42 Uhr UTC

Groovy: 1.8.6

Ant: Apache Ant™ version 1.8.4 compiled on May 22 2012

Ivy: 2.2.0

JVM: 1.7.0_09 (Oracle Corporation 23.2-b09)

OS: Linux 3.2.0-37-generic amd64

real

0m3.699s

user

0m4.764s

sys

0m0.224s

$ time gradle --offline

:hello

Hello world!

BUILD SUCCESSFUL

Total time: 10.224 secs

real 0m10.615s

user

0m15.769s

sys

0m0.560s

At least I’m pretty sure it’s not a networking issue, but I have no clue what else it could be.

I’ve pasted a debug-level log at https://gist.github.com/toolforger/4751302 .


(Stephane Galles) #8

Yes, actually the --offline flag did not work either in my case, but it really was a networking issue though


(Peter Niederwieser) #9

Try to:

  • Plug out your network cable / turn off Wifi. * Rename ‘/home/jo/.m2’ so that Gradle won’t find it.

(toolforger) #10

Pulling out the network cable: No change. Having the network cable pulled out AND .m2 renamed: No change.


(Peter Niederwieser) #11

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


(toolforger) #12

OS: Linux 3.2.0-37-generic amd64

All files stored locally.

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.


(Peter Niederwieser) #13

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?


(toolforger) #14

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:

$ java -version

java version “1.7.0_09”

OpenJDK Runtime Environment (IcedTea7 2.3.4) (7u9-2.3.4-0ubuntu1.12.04.1)

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


(Szczepan Faber) #15

Can you run gradle with --profile ? It might tell us something.


(Peter Niederwieser) #16

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.


(Peter Niederwieser) #17

Completely forgot about that. :slight_smile:


(toolforger) #18

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


(toolforger) #19

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.


(Peter Niederwieser) #20

I’d recommend to use a Java profiler and attach it to an external Gradle process.