Nail your Gradle build time
summary
Company with 20+ teams and hundreds of build hours weekly reduces Gradle time by measure every build, using a small build-listener plugin to record median incremental and P90 clean times, Gradle scans and Gradle Enterprise for profiling, and experiments like build-twice, nuke cache and remote-cache pulls. Modular rules and tiny API modules cut the longest-path; merging some modules shaves clean builds. Remote cache halves CI time but suffers from network and JDK mismatches; observed module cost ~400ms (now ~150ms) and ~60% faster incremental builds.
AI-written summary · about
chapters (8)
- 0:00Introduction to Gradle build time
- 1:05Why build time matters
- 8:07Measuring build time metrics
- 13:30Modularization impact on builds
- 21:53Caching strategies for Gradle
- 27:51Experimentation and debugging builds
- 34:08Results and key learnings
- 38:59Q&A and closing remarks
related talks
35mGradle recipes for reducing your build times
33mKeeping your Gradle builds in top shape
17mBoosting your Android CI through integrating Build Cache
41mSpeeding up Jenkins, Gradle, and Maven with a Build Cache
30mHow we brought down our build times. General optimization tips
32mFaster Feedback Cut Gradle Build and Pipeline Times in Half
54mFrom Laptop Builds to Advanced CI
20mMaximize development efficiency with expert CI/CD strategies