Is there any way to prioritize tasks in a parallel build

Is there anyway to prioritize tasks in a parallel build, or maybe a plugin that records task timings and schedules the tasks for optimal throughput on the currently selected number of workers? We’re trying to reduce build time at where I work, and we notice that a) some threads start being unused about halfway through and b) the longest tasks happen at the end. We’d like to nudge gradle to wait on some of the smaller tasks if it means that it can get some of those bigger tasks scheduled sooner.

You can use Task.shouldRunAfter to nudge Gradle to try to execute some tasks later.

smallTask.shouldRunAfter bigTask

If you want to list a whole bunch of short and long tasks, you can also use this notation:

[shortTask1, shortTask2, shortTask3, shortTask4]*.shouldRunAfter longTask1, longTask2, longTask3

Hi Sam,

Build scans provide a visualisation of task parallelisation. You can see an example here: https://scans.gradle.com/s/qht2chux7uqzk#timeline

This doesn’t give an automated solution to optimisation, but it’s an easy way to reason about the scheduling for a particular build. If you’re interested, you can find out more about build scans @ https://scans.gradle.com/get-started.

What are the semantics of shouldRunAfter? I know it’s not as strong a guarantee as mustRunAfter, but beyond that, I’m not sure what doing that entails. So I have a couple questions:

  • I’m assuming shouldRunAfter promises will be broken if they create cycles, correct?
  • Does a shouldRunAfter promise get broken if there are idle threads that can only run tasks that would break the shouldRunAfter guarantee? E.g. for parallel builds. I’d love it if it did. I guess I could throw together a test to find out…

I guess what I’m really looking for is a “shouldStartAfter”… waiting for the previous task to finish isn’t quite what I’m after.

shouldRunAfter won’t create cycles. Its cousin mustRunAfter could though.

You can find some details here: https://docs.gradle.org/current/userguide/more_about_tasks.html#sec:ordering_tasks

Yes, on both counts. No cycles and it won’t stop a task from executing if could otherwise in parallel.

Oh, that’s great! I didn’t realize it was in that documentation, I should have reviewed that better. Thank you so much for the help, James and Luke.