Would like the ability to stop the gradle daemon from flutter tool

[jamesderlin]

I regularly see gradle consuming nearly 700+ MB of RAM on my Linux system. I consider that to be a lot, especially when it's sitting there doing nothing.

The path to my gradle binary is convoluted (e.g. ~/.gradle/wrapper/dists/gradle-4.4-all/9br9xq1tocpiv8o6njlyu5op1/gradle-4.4/bin/gradle) and changes with gradle versions, so manually invoking gradle --stop is non-trivial.

Additionally, the flutter tool tries to abstract away build processes for Android (and iOS) apps, so many users might not even know what gradle is or why it's running. Since flutter run started the gradle daemon, it'd be nice if the flutter tool also provided some mechanism to stop it.

I mentioned this in chat a few months ago. @dnfield considered disabling the gradle daemon unless the user opts in. I suggested making flutter stop (possibly with a command-line option) stop the gradle daemon, but @Hixie didn't like that since it's not really what stop is meant for. He suggested adding a command-line option to flutter clean to do it.

Some other ideas:

• Automatically stop gradle if flutter run hasn't been used in some time. (But this would require some other daemon. Ideally gradle would provide the ability to do this itself.)
• Automatically stop gradle when there's no longer a connected device. (But even if there is a way to be notified of this, this probably also would need some other process.)

[dnfield]

What if you just have gradle (any version that knows gradle stop) available on your path? Does it need to be the same version as used for the wrapper?

[jamesderlin]

That's actually exactly what I had been doing, but recently I noticed that gradle --stop always told me that there were no running gradle daemons. Eventually I figured out that it was because flutter run was spawning a different version of gradle. =(

[jonahwilliams]

Presumably if you flutter run an Android application we should terminate the corresponding Gradle daemon when the run completes?

[jonahwilliams]

Actually, I think that daemon might be shared by different processes ... erm

[jamesderlin]

Another problem is that when I upgrade Flutter, if it uses a new version of gradle, I can end up with multiple gradle instances running. =(

[dnfield]

Do we have a sense of how much time the gradle daemon actually saves us on subsequent rebuilds? Would it be better to just disable it by default, and maybe have a flag to allow the user to use it if they want?

[dnfield]

@blasten - in your work with Gradle lately, have you noticed a nice way we could start/stop this?

I suspect that now that we build plugins as AARs, we'd want to potentially start the daemon and stop it after the run.

Alternatively, we could guard it by a feature flag - but I'm not sure when opting in would make sense (it could make multiple builds faster but you'd have no idea how/when to safely kill it).

[blasten]

@dnfield while we are waiting for the gradlew process, we could install a ProcessSignal.sigterm handler and kill the daemon using .../android/gradlew --stop. This seems to work as long as we use the same gradlew script.

[dnfield]

where would you install the signal handler?

[blasten]

The tool itself. My thinking is that killing the tool should result in stopping the daemon.

[dnfield]

I'm not sure how that would impact the IDE plugins, and I'm not sure what would happen if you had multiple instances of the tool running all trying to use the same gradle daemon...

[blasten]

flutter run/attach might be a special case since we release the lock early.

Side note: gradlew --status gives you the list of processes:

$ ./gradlew --status
   PID STATUS   INFO
 63298 IDLE     4.10.2
 65382 BUSY     4.10.2
 65350 IDLE     4.10.2

kill the daemon if 65382 started by the current instance of the tool and the remaining processes are IDLE.