[GRADLE-1098] Reduce test execution time Created: 09/Aug/10  Updated: 10/Feb/17  Resolved: 10/Feb/17

Status: Resolved
Project: Gradle
Affects Version/s: None
Fix Version/s: None

Type: Improvement
Reporter: Chris Beams Assignee: Unassigned
Resolution: Won't Fix Votes: 1


 Description   

Quoting Adam:

On linux, I get:
gradle clean test 8.12s
mvn clean test 8.75s

Actually I can see this. Some more measurements:

gradle clean testClasses 3.20s
mvn clean test-compile 7.48s

So, there's 4.92s for Gradle to run the tests, vs 1.27s for Maven to run them. Yikes.

Disabling the HTML Junit report (which Maven is not generating in this test) brings the times down to

gradle clean test 6.71s
mvn clean test 8.75s

So now, we're at 3.51s vs 1.27s.

Some quick instrumentation verifies that we're actually spending almost all of that time in the Test.executeTests() method. Next step is to fire up the profiler and see what's going on.

 Comments   
Comment by Adam Murdoch [ 10/Aug/10 ]

Nothing obvious from the profiler. Some instrumentation shows a bit of a break-down of the execution time:

  • time in the test task: 3.24s
  • run time for test processes: 2.49s
  • test execution time in test processes: 1.32s
Comment by Magnus Rundberget [ 29/Mar/11 ]

By running gradle (1.0 milestone 1) with -d on a very simple project with a couple of unit tests I noticed
a serious lag for start running the actual tests. Check out my sample log below. Especially the following two lines;
16:06:34.949 [DEBUG] [org.gradle.process.internal.DefaultExecHandle] Started Gradle Worker 1.
16:06:36.259 [QUIET] [system.out] 16:06:36.254 [DEBUG] [org.gradle.messaging.remote.internal.TcpOutgoingConnector] Found loop-back addresses: [/127.0.0.1, /0:0:0:0:0:0:0:1].

        • Log output from gradle --daemon clean test -d (second pass) ******
          16:06:34.853 [DEBUG] [org.gradle.process.internal.ProcessBuilderFactory] creating process builder for Gradle Worker 1
          16:06:34.853 [DEBUG] [org.gradle.process.internal.ProcessBuilderFactory] in directory /Users/magnus/Documents/Kodemaker/lyntaler/Gradle/dumpling/dumpling-core
          16:06:34.854 [DEBUG] [org.gradle.process.internal.ProcessBuilderFactory] with argument#0 = -ea
          16:06:34.854 [DEBUG] [org.gradle.process.internal.ProcessBuilderFactory] with argument#1 = -cp
          16:06:34.854 [DEBUG] [org.gradle.process.internal.ProcessBuilderFactory] with argument#2 = /Users/magnus/.gradle/caches/1.0-milestone-1/workerMain/classes
          16:06:34.854 [DEBUG] [org.gradle.process.internal.ProcessBuilderFactory] with argument#3 = org.gradle.process.internal.launcher.GradleWorkerMain
          16:06:34.949 [DEBUG] [org.gradle.process.internal.DefaultExecHandle] Started Gradle Worker 1.
          16:06:36.259 [QUIET] [system.out] 16:06:36.254 [DEBUG] [org.gradle.messaging.remote.internal.TcpOutgoingConnector] Found loop-back addresses: [/127.0.0.1, /0:0:0:0:0:0:0:1].
          16:06:36.263 [QUIET] [system.out] 16:06:36.261 [DEBUG] [org.gradle.messaging.remote.internal.TcpOutgoingConnector] Trying to connect to address /127.0.0.1.
          16:06:36.274 [DEBUG] [org.gradle.messaging.remote.internal.TcpIncomingConnector] Accepted connection from tcp://localhost:50441.
          16:06:36.278 [QUIET] [system.out] 16:06:36.277 [DEBUG] [org.gradle.messaging.remote.internal.TcpOutgoingConnector] Connected to address /127.0.0.1.
          16:06:36.363 [QUIET] [system.out] 16:06:36.362 [DEBUG] [org.gradle.process.internal.child.ActionExecutionWorker] Starting Gradle Worker 1.
          16:06:36.364 [QUIET] [system.out] 16:06:36.364 [INFO] [org.gradle.api.internal.tasks.testing.worker.TestWorker] Gradle Worker 1 executing tests.
          16:06:36.449 [DEBUG] [org.gradle.api.tasks.testing.Test] Started test process 'Gradle Worker 1'
Comment by Benjamin Muschko [ 15/Nov/16 ]

As announced on the Gradle blog we are planning to completely migrate issues from JIRA to GitHub.

We intend to prioritize issues that are actionable and impactful while working more closely with the community. Many of our JIRA issues are inactionable or irrelevant. We would like to request your help to ensure we can appropriately prioritize JIRA issues you’ve contributed to.

Please confirm that you still advocate for your JIRA issue before December 10th, 2016 by:

  • Checking that your issues contain requisite context, impact, behaviors, and examples as described in our published guidelines.
  • Leave a comment on the JIRA issue or open a new GitHub issue confirming that the above is complete.

We look forward to collaborating with you more closely on GitHub. Thank you for your contribution to Gradle!

Comment by Benjamin Muschko [ 10/Feb/17 ]

Thanks again for reporting this issue. We haven't heard back from you after our inquiry from November 15th. We are closing this issue now. Please create an issue on GitHub if you still feel passionate about getting it resolved.

Generated at Wed Jun 30 11:46:50 CDT 2021 using Jira 8.4.2#804003-sha1:d21414fc212e3af190e92c2d2ac41299b89402cf.