skip to content

Walk me through the Performance tab of a Build Scan. What breakdown does it give you and how do you use it to decide where to optimize?

level: middleimportance: must knowfreq 55%

answer

  1. phase breakdown
  2. configuration vs execution
  3. serial vs parallel time
  4. cache hit/miss summary
  5. triage screen

basics

~20 s

The Performance tab splits total build time into phases — startup, settings/configuration, and task execution — and breaks execution into serial vs parallel time. You use it to see whether time went into configuration or execution before drilling in.

solid answer

~40 s

The **Performance** tab gives a phase-level breakdown of the build's wall-clock time: **startup**, **settings & buildSrc**, **configuration**, and **task execution**. For execution it shows **serial vs parallel** time and the effective parallelism achieved. It also surfaces a **build cache** sub-view summarizing cache hits/misses and the time saved by avoidance. The decision flow: if configuration time is large relative to execution, you have a configuration problem (eager task creation, expensive `afterEvaluate` work) and configuration caching is the lever. If execution dominates but parallelism is poor (lots of serial time), you look at task dependencies, `--max-workers`, and module structure. If execution dominates and parallelism is fine, you attack the slowest tasks themselves and improve cacheability. The Performance tab is the triage screen; the Timeline is where you confirm specifics.

code

toml · 5 lines
toml
# gradle.properties — levers the Performance tab points you toward
org.gradle.parallel=true
org.gradle.caching=true
org.gradle.configuration-cache=true
org.gradle.workers.max=8

go deeper

for a junior

Know the tab splits time into startup/configuration/execution and that configuration runs every build.

for a middle

Use serial-vs-parallel numbers and the cache summary to choose between config-cache, parallelism, and cacheability fixes.

for a senior

Quantify ROI from the avoidance-savings figure and tie phase costs to specific structural changes.

for a principal

Standardize Performance-tab triage as a team practice and set wall-clock/parallelism targets enforced via Develocity dashboards.

## Purpose of the Performance tab Where the **Timeline** is per-task, the **Performance** tab is per-**phase**. It answers: *of the total wall-clock time, how much went into each stage of the build lifecycle, and how well did execution parallelize?* ## The phases it breaks out Gradle runs a build in distinct phases, and the Performance tab attributes time to each: - **Startup** — JVM/daemon spin-up, plugin classpath loading. - **Settings and buildSrc** — evaluating `settings.gradle(.kts)` and building `buildSrc` if present. - **Configuration** — evaluating every project's build script and registering tasks. This is the phase that runs *every* build regardless of which tasks you invoke. - **Task execution** — actually running the requested tasks. ## Serial vs parallel execution Within execution, the tab reports **total task time** versus **wall-clock execution time**. If you summed 120s of task work but the build's execution phase took only 40s wall-clock, you achieved ~3x parallelism. A large gap *the wrong way* — total task time close to wall-clock — means tasks ran mostly serially and there's headroom in `org.gradle.parallel`, `--max-workers`, or module decomposition. ## The build cache sub-view The Performance tab summarizes **cache outcomes**: how many tasks were `FROM-CACHE`, how many missed, how many were not cacheable, and an estimate of **avoidance savings** (time you did *not* spend because outputs were restored). This connects directly to ROI: a low hit rate on expensive tasks is the highest-value fix. ## How to triage with it ```text Phase Wall-clock startup 1.2s settings/buildSrc 0.4s configuration 14.8s <-- large: investigate eager work / config cache execution 52.0s serial 48.0s <-- poor parallelism parallel 4.0s ``` 1. **Configuration heavy?** Enable `org.gradle.configuration-cache=true`, hunt eager `tasks.create`/`getByName`, prefer `tasks.register` (lazy). 2. **Execution serial?** Turn on parallel execution, raise workers, reduce cross-project task dependencies. 3. **Execution dominated by a few tasks?** Make them cacheable (`@CacheableTask`) and jump to the Timeline to optimize them.

  • If the Performance tab shows configuration time growing every build, what's the first lever?
    Enable the configuration cache so the configured task graph is serialized and reused, and audit for eager task creation that should be lazy (tasks.register).
  • How does the Performance tab quantify parallelism?
    It compares summed task time against wall-clock execution time; a large positive ratio means good overlap, while near-equal values mean tasks ran serially.
  • Why is configuration time especially worth attacking?
    Configuration runs on every invocation regardless of the requested task, so it's a fixed tax on all builds — paying it down speeds up even incremental, mostly-cached runs.

The Performance tab is the triage nurse — it tells you which system is failing (config vs execution vs cache). The Timeline is the specialist who diagnoses the exact task.

saying these in an interview costs you the question

  • Conflating the Performance tab's phase breakdown with the Timeline's per-task view.
  • Treating high total task time as a problem when parallelism already absorbed it into low wall-clock time.

context

resolving links…