On Debian Unstable, when issuing a gradle command on the Bash command line, for example:
|> gradle clean :clean
BUILD SUCCESSFUL
Total time: 3.587 secs
it then takes 4 or 5 seconds for the command to complete and the Bash prompt to appear. This has to be seen as a bug.
3.5 seconds doesn’t seem out of the world; I get 2.5 seconds on my brand-new Mac. To avoid the startup overhead, enable the Gradle daemon.
You miss my point. Gradle doing things for 3.5 seconds and then printing a message is fine, per se. Gradle then delaying a further 4 or 5 seconds before terminating after printing the the message is unacceptable. If there is more to be done after the build is complete then Gradle should not be printing a message that is untruthful, it should delay printing the message and the timing till the very end and be printing 7 seconds after it is all done.
I don’t want daemons, I want a truthful report.
This is about good UI and UX nothing more.
Can you try again with increased memory settings? Where is the time spent according to ‘top’? I doubt that Gradle is actively doing something here.
htop reports using 400% of my CPU during the actual cleaning and 200% of my CPU in the waiting period after completion. I am not sure of how to collect proper data that can be useful.
I would have thought the default memory setting would be fine. Anyway this is JDK 8 which has the G1 GC and so should cope.
Can you tell what the user/system CPU time ratio is for the waiting period? Does the problem also occur for a “hello world” build? Can you try with a released version of JDK7? Maybe Debian unstable is having a bad day? 
With JDK 8:
|> time gradle clean :clean UP-TO-DATE
BUILD SUCCESSFUL
Total time: 2.767 secs
real 0m8.349s user 0m14.069s sys 0m0.336s
With JDK7
|> (export JAVA_HOME=$HOME/lib.Linux.x86_64/JDK7 ; time gradle clean) :clean UP-TO-DATE
BUILD SUCCESSFUL
Total time: 3.327 secs
real 0m3.443s user 0m6.348s sys 0m0.272s
So this is clearly either: