skip to content

What does the --profile flag do, and what kind of build slowness is it good at surfacing?

level: middleimportance: should knowfreq 45%

answer

  1. HTML report under build/reports/profile/
  2. phase breakdown: configuration vs execution
  3. per-task durations, sortable
  4. dependency resolution timing
  5. cheap local triage, no account

basics

~10 s

--profile makes Gradle write a timestamped HTML report under build/reports/profile/ that breaks the build down by phase — startup, settings/configuration, and task execution — so you can see where wall-clock time went.

solid answer

~40 s

`--profile` instruments the build and emits an HTML report to `build/reports/profile/profile-<timestamp>.html`. At a glance it surfaces *which phase* dominated: **total build time** split into startup, settings & buildSrc, **configuration** (per-project evaluation time), **dependency resolution**, and **task execution** (per-task durations, sortable). Its main value is triage: it tells you cheaply whether your pain is configuration-time (e.g. an expensive plugin evaluating every project) or execution-time (a few slow tasks), so you know where to dig. It's local, needs no account, and is a good first stop before reaching for a richer build scan. The trade-off: it's a snapshot of one invocation with less drill-down than a scan.

code

bash · 3 lines
bash
./gradlew build --profile
# -> build/reports/profile/profile-<timestamp>.html
open build/reports/profile/*.html   # macOS

go deeper

for a junior

Know it writes an HTML timing report under build/reports/profile/.

for a middle

Explain the phase breakdown (startup/configuration/dependency resolution/execution) and that it's local with no account.

for a senior

Use it for triage — distinguishing configuration-bound vs execution-bound slowness — and know its limits vs a scan.

for a principal

Frame it in a measurement strategy: cheap local first pass, escalate to scans for cross-build correlation; tie findings to configuration cache / build cache adoption.

## What --profile produces Adding `--profile` to any invocation tells Gradle to record timing for the whole run and write a self-contained HTML file: ``` build/reports/profile/profile-2026-06-30-14-22-08.html ``` Open it in a browser. There's no extra setup, no account, no network call. ## What's in the report (phase breakdown) The report groups time into the same phases Gradle actually runs, which is exactly why it's useful for triage: - **Summary** — total elapsed time and the share taken by configuration vs execution. - **Configuration** — time spent evaluating each project's build script. A heavy plugin or eager work that runs for every subproject shows up here, multiplied by project count. - **Dependency Resolution** — time resolving each configuration's dependencies (useful when a repository is slow or a version range forces extra metadata fetches). - **Task Execution** — every task that ran, with its duration, sortable so the slowest float to the top. ## What it's GOOD at - Answering "is my slowness in configuration or in execution?" — the single most important triage question, because the fixes differ completely. - Spotting a small number of dominant slow tasks. - Catching configuration cost that scales with the number of subprojects. ## What it's WEAKER at - It's a **single-invocation snapshot** with limited drill-down. It won't tell you *why* a task was slow internally, won't show cache hit/miss insight the way a scan does, and won't correlate across many builds. - It does not itself fix anything — it points you at the phase, then you use phase-specific tools (configuration cache, build cache, parallel execution) to actually improve things. ## How it pairs with other flags Think of a layered toolkit: ``` --dry-run -> what WILL run (graph shape) --profile -> where time WENT, by phase (cheap triage) build scan -> deep drill-down + sharing (richer, optional account) ``` Start cheap and local with `--profile`; escalate only if you need more detail.

  • Where is the report written and what format is it?
    A timestamped HTML file under build/reports/profile/, e.g. profile-2026-06-30-14-22-08.html. It's self-contained and opens in any browser with no account needed.
  • If --profile shows configuration dominating total time, what's your next move?
    Look for a plugin or eager work running per-project, and consider enabling the configuration cache and lazy task registration so configuration cost is paid once and reused.

saying these in an interview costs you the question

  • Saying --profile uploads data to a server or needs an account (it's purely local HTML).
  • Confusing --profile with --scan; the scan is the richer, optionally-shared tool.

context

resolving links…