12 Quick Tips From the Gradle Enterprise Workshop

The team at Gradle held their Enterprise Workshop to help diagnose build performance issues, shorten the feedback cycle between compiling and running code, and improve toolchain reliability. Furthermore, there was a short introduction by Airbnb about how they use Gradle Enterprise and treat developer productivity. This post will cover many of the small build performance tips presented by Airbnb and Gradle, without focusing on the offerings of Gradle Enterprise.

Airbnb's tips

1. Detect flakey tests and get rid of them. Airbnb uses a private tool, called Arborist, to do this, but it can be done manually too.
2. Build scans are incredibly important to finding slow Gradle tasks. They provide historical data which allow build performance engineers to triage the highest impact issues.
3. Build scans provide a convenience for diagnosing build issues. A software engineer does not need to be colocated with the build engineer to find an issue, allowing for faster turnaround time.

Gradle's tips

1. Toolchain efficiency importance grows as team size grows. More developers lead to a larger code size, number of libraries, and complexity of modules.
2. Developer happiness is directly related to developer productivity. A developer does not want to wait for code to compile, and even worse does not want to see build times increase over time.
3. Build performance improvements are difficult to pitch to those in product since it does not directly tie in with metrics like user revenue or new user growth. However, wasted developer time is much easier to pitch as it controls how much can be completed in a development cycle.
4. To calculate build performance improvement, a simple equation such as build time * num local builds = total loss can help convince those in product. A team of five people can gain ten to twenty hours per week of valuable programming time with a 25 percent improvement in build performance.
5. Build scans (./gradlew build --scan) analyze your build and suggest performance enhancements. If you use Gradle and haven't used build scans before, then I hope you try it and see the magic yourself. Even better, they're free!
6. An easy gain in build performance is to convert some of your eager Gradle API usages to lazy API usages. Use build scans to see the difference.
7. Another build performance tip is to move file system and network access out of the Gradle configuration phase and into execution.
8. Timestamps (System.currentTimeMillis()) generated in Gradle tasks can prevent the task from being cached, causing a huge performance hit. The Gradle build system can be told to ignore the "volatile" property.
9. Performance regressions easily happen over time. A developer can add a useful annotation library, unknowingly causing huge amounts of generated code to be built. The most reliable way to prevent build performance loss over time is to measure it and flag regressions.

Comments

[Harsh Shandilya]

Thanks for the roundup!