skip to content

Walk through the sections of the --profile HTML report and what each one tells you.

level: middleimportance: must knowfreq 48%

answer

  1. Summary / Configuration / Dependency Resolution / Task Execution
  2. per-project config time
  3. per-configuration resolve time
  4. tasks slowest-first + outcome
  5. wall-clock, single build

basics

~10 s

The report has a Summary plus Configuration (per-project config time), Dependency Resolution (per-configuration resolve time), and Task Execution (per-task time with outcome). You read Summary first, then drill into the dominant phase.

solid answer

~40 s

The profile report mirrors Gradle's build phases. **Summary** gives total wall-clock time and a high-level split (configuration vs execution). **Configuration** lists each project and how long configuring it took — high values flag expensive script logic and motivate the configuration cache. **Dependency Resolution** shows time to resolve each `Configuration` such as `compileClasspath`/`runtimeClasspath`, surfacing slow repos or large graphs. **Task Execution** lists every task that ran, sorted slowest-first, with its duration and outcome (`EXECUTED`, `UP-TO-DATE`, `FROM-CACHE`, `NO-SOURCE`, `SKIPPED`). Reading flow: open Summary to find the dominant phase, then jump to that phase's section. Note the report is purely **wall-clock** and **single-build** — it tells you where time went on this run but not why a task wasn't cached; for that you combine it with --info or a Build Scan.

code

bash · 3 lines
bash
# Warm the daemon, then capture a representative profile
./gradlew help > /dev/null
./gradlew clean build --profile

go deeper

for a junior

Name the sections and that each maps to a build phase.

for a middle

Explain what each section measures and the read-Summary-then-drill workflow, including task outcomes.

for a senior

Tie sections to concrete fixes (config cache for configuration time, repo/graph tuning for resolution, cacheability for execution) and call out wall-clock/single-run limits.

for a principal

Use the section breakdown to decide org-level investments (config cache rollout, internal mirrors, remote build cache) rather than per-build tweaks.

## The phases, mirrored as sections A Gradle build runs in ordered phases — **initialization**, **configuration**, then **execution** — and the profile report exposes the parts that usually dominate. ### Summary The landing view: total elapsed time and a coarse split between configuration and execution, plus startup/init overhead. Use it to decide *where to look next* rather than guessing. ### Configuration One row per configured project, showing how long Gradle spent **configuring** it — i.e. running the build-script body and registering tasks (note: *registering* a task is cheap, but doing real work at configuration time is not). Large numbers here mean eager/expensive configuration logic. The fix is usually lazy APIs (`tasks.register` over `tasks.create`, `Provider`/`Property`) and enabling the **configuration cache**, which serializes the configured task graph so configuration is skipped on subsequent runs. ### Dependency Resolution One row per resolved `Configuration` (e.g. `compileClasspath`, `runtimeClasspath`, `testRuntimeClasspath`) with the time to resolve it. Resolution walks the dependency graph and may download metadata/artifacts. Spikes point at slow or distant repositories, missing caches, or very large graphs. It also helps spot accidental resolution *at configuration time* (resolving a configuration too early is a known anti-pattern). ### Task Execution The meat for most slow builds: every task that actually ran during execution, **sorted slowest-first**, with duration and **outcome**: - `EXECUTED` — did real work - `UP-TO-DATE` — skipped via incremental build (inputs/outputs unchanged) - `FROM-CACHE` — pulled from the build cache - `NO-SOURCE` / `SKIPPED` — nothing to do Seeing an expensive task as `EXECUTED` when you expected `UP-TO-DATE`/`FROM-CACHE` is your signal to investigate inputs/outputs and cacheability. ## Reading strategy ``` Summary -> pick dominant phase | +-- configuration heavy? look at Configuration tab -> config cache, lazy APIs +-- resolution heavy? look at Dependency Resolution -> repos, graph size +-- execution heavy? look at Task Execution -> slowest EXECUTED tasks ``` Because numbers are wall-clock and from one run, take a warm-daemon, repeated measurement before drawing conclusions.

  • If the Configuration section dominates, what's the typical remedy?
    Reduce eager configuration work (use tasks.register and lazy Provider/Property APIs) and enable the configuration cache so the task graph is reused.
  • What does a FROM-CACHE outcome in Task Execution tell you?
    The task's outputs were restored from the build cache instead of being recomputed — good; an EXECUTED task you expected to be cached signals a cacheability problem.
  • Why might a Configuration appear in Dependency Resolution unexpectedly?
    Something resolved it (e.g. configuration-time resolution); excessive or early resolution is an anti-pattern worth fixing.

saying these in an interview costs you the question

  • Saying the report shows JVM/GC internals — it shows build-phase wall-clock, not heap profiling
  • Claiming Task Execution lists tasks alphabetically — it's slowest-first
  • Treating a single cold run's numbers as authoritative

context

resolving links…