Improve build speed by altering gradle.properties

[fractalwrench]

Goal

This PR attempts to improve the build speed and overall build performance of the project by adopting Gradle's suggested practices. This is loosely based on the performance tweaks we've adopted at Embrace over the last couple of years. Changes include:

1. Increasing the maximum heap size of the build
2. Various tweaks to JVM options for Gradle and the Gradle daemon that allow it to obtain more memory, if required
3. Enables parallel execution, which allows unrelated Gradle tasks to run in parallel rather than sequentially
4. Enables build caching
5. Enables configuration caching, which can drastically reduce the time required for the configuration phase of the build
6. Enables parallel storing of the configuration cache

Not all gradle plugins/build scripts are compatible with Gradle's configuration cache as the ecosystem has been moving over. The build has been configured to fail if known problems are detected.

Testing

I used the following command on my local machine:
./gradlew assembleRelease check --no-configuration-cache --no-build-cache --rerun-tasks --scan

A baseline took 6m39s, and with the changeset this took 5m19s. I would expect more performance gains than this in practice given that the benchmarking command disabled configuration/build cache & ran all tasks from scratch.

Future work

The demo-app could have the same settings applied as it's a separate Gradle project. Or, we could consider combining it into one Gradle project so that it's not necessary to run two gradle builds sequentially.

[linux-foundation-easycla]

The committers listed above are authorized under a signed CLA.

• ✅ login: fractalwrench / name: Jamie Lynch (010794b, 3a66f0f)

[bidetofevil]

LGTM. A completely unscientific perusal of the past ~10 "PR build" GitHub action runs suggest that this will improve things, so it feels right to do, especially since we are just following the Gradle recommendations

[LikeTheSalad]

I think that enabling parallel task execution should do most of the job. Tbh I don't know enough about how GH machines work to be sure that something that's cached on one machine (regarding enabling build and config cache) would work for a further action run that might happen on a different machine?

It's not a blocker, though, I'm mostly curious. Thanks for taking the time to address this issue 🙏

[fractalwrench]

@LikeTheSalad the setup-gradle action stores build state in Github's cache so it's available for subsequent runs. For a real-life example, here's Embrace's CI caches.

[LikeTheSalad]

@LikeTheSalad the setup-gradle action stores build state in Github's cache so it's available for subsequent runs. For a real-life example, here's Embrace's CI caches.

Sounds good, thanks for the explanation!

[breedx-splk]

I'm down to try this for sure. My only hesitation is that we probably still want to make sure that we're NOT caching when we run the final release build, right? In that case, we probably want to add --no-build-cache to the release.yml too?

[fractalwrench]

That sounds sensible. I've updated the release command so that it doesn't use build cache, parallel execution, or configuration cache.

[breedx-splk]

Thanks! Unfortunately, I think this is the safest way to get a consistent build output.