[GRADLE-1148] Tasks run against long-idle Gradle daemon experience significant delay Created: 13/Sep/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: | 0 |
Description |
Consider the following - two immediately subsequent runs of a task against a GradleDaemon process that has been running for at least several days. Prior to the first run, no tasks had been executed against that daemon for at least 48 hours. The first run takes 100x as long as the second. I've noticed this behavior before, but this is the first time I've captured it. It's as if the remote JVM is experiencing some overhead due to 'waking up' after long inactivity. cbeams@anakata:~/Work/spring-framework/env-sandbox[master]>$ ./gradlew clean :clean BUILD SUCCESSFUL Total time: 38.846 secs cbeams@anakata:~/Work/spring-framework/env-sandbox[master]>$ ./gradlew clean :clean UP-TO-DATE BUILD SUCCESSFUL Total time: 0.346 secs Toward reproducibility, it seems one will not have to wait for days of JVM inactivity to reproduce. Just in the time it took me to write this issue, the delay seems to manifest itself again, albeit much less dramatically. Here are the results of two more runs: cbeams@anakata:~/Work/spring-framework/env-sandbox[master]>$ ./gradlew clean :clean UP-TO-DATE BUILD SUCCESSFUL Total time: 4.483 secs cbeams@anakata:~/Work/spring-framework/env-sandbox[master]>$ ./gradlew clean :clean UP-TO-DATE BUILD SUCCESSFUL Total time: 0.145 secs And again, after writing the above, I've tried some more runs, and these seem to contradict the "JVM inactivity" hypothesis above. Notice the timestamps before each run - they're all immediately subsequent to one another, and yet some take 2.5 seconds or more, while others take 1/100th of a second. Now it seems like an OS/process scheduling issue, but that does not seem sufficient to explain the original 30+ second run after days of inactivity. Perhaps there are multiple factors at play here. |
Comments |
Comment by Chris Beams [ 13/Sep/10 ] |
Oops, missed posting the last batch of task executions with timestamps as mentioned. Here they are: cbeams@anakata:~/Work/spring-framework/env-sandbox[master]>$ date; ./gradlew clean Mon Sep 13 11:06:30 CEST 2010 :clean UP-TO-DATE BUILD SUCCESSFUL Total time: 2.506 secs cbeams@anakata:~/Work/spring-framework/env-sandbox[master]>$ date; ./gradlew clean Mon Sep 13 11:06:34 CEST 2010 :clean UP-TO-DATE BUILD SUCCESSFUL Total time: 1.958 secs cbeams@anakata:~/Work/spring-framework/env-sandbox[master]>$ date; ./gradlew clean Mon Sep 13 11:06:38 CEST 2010 :clean UP-TO-DATE BUILD SUCCESSFUL Total time: 0.085 secs cbeams@anakata:~/Work/spring-framework/env-sandbox[master]>$ date; ./gradlew clean Mon Sep 13 11:06:40 CEST 2010 :clean UP-TO-DATE BUILD SUCCESSFUL Total time: 2.132 secs cbeams@anakata:~/Work/spring-framework/env-sandbox[master]>$ date; ./gradlew clean Mon Sep 13 11:06:44 CEST 2010 :clean UP-TO-DATE BUILD SUCCESSFUL Total time: 0.098 secs |
Comment by Robert Fischer [ 08/Jan/11 ] |
Is your computer's RAM overloaded? It sounds like the Gradle daemon moving into swap and having to be fetched back. Also, is it reproducible through an install and not through the wrapper? |
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:
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. |