skip to content

A teammate claims keeping the daemon alive 'doesn't help much.' How would you measure the real throughput impact of warmup versus a cold start for your project?

level: middleimportance: should knowfreq 28%

answer

  1. warm series: run 4–5x, watch curve flatten
  2. cold baseline: --stop then --no-daemon
  3. gap = warmup benefit
  4. --profile / --scan to attribute phases
  5. control inputs, take medians

basics

~10 s

Run the same build several times in one daemon and record each duration; then run it again with the daemon killed/disabled. Compare the cold run against the warm steady-state to quantify the warmup savings.

solid answer

~50 s

Measure, don't guess. Pick a representative invocation (e.g., a no-op `help` or a fixed task), then: (1) **Warm series** — keep one daemon alive and run the build 4–5 times back to back, recording each wall time; you'll see the **decaying warmup curve** flatten to a steady state. (2) **Cold baseline** — stop daemons (`--stop`) or run `--no-daemon` to force a cold JVM, and time that. The gap between the cold run and the warm steady-state is the warmup benefit for *this* project. Use Gradle's `--profile` reports or build scans to attribute time to phases (configuration vs. execution) and confirm the savings are in build-logic CPU, not task work. Control variables: same inputs, no concurrent load, exclude first cache-population run. For short builds you'll typically see a meaningful percentage; for long builds the warmup is amortized and the teammate may be right — which is exactly why you measure rather than assume.

code

bash · 4 lines
bash
# Warm steady-state vs. cold baseline
./gradlew --stop && ./gradlew help && ./gradlew help && ./gradlew help  # warm curve
./gradlew --stop && ./gradlew help --no-daemon                          # cold baseline
./gradlew help --profile   # phase breakdown (configuration vs execution)

go deeper

for a junior

Know to time the same build a few times warm, then once cold, and compare.

for a middle

Set up a controlled warm-series vs. cold-baseline experiment and use --profile to attribute the time.

for a senior

Discuss isolating warmup from cache population, noise control with medians, and the short- vs. long-build regimes.

for a principal

Define a standard benchmarking methodology for the org so performance claims are evidence-based across pipelines.

## Turn opinion into data Claims like 'the daemon doesn't help' are testable. Set up a clean, controlled comparison. ### 1. Establish the warm steady-state Keep a single daemon alive and run the **same** build repeatedly: ```bash ./gradlew --stop # ensure a known cold start ./gradlew help # run 1 (cold-ish, populates daemon) ./gradlew help # run 2 ./gradlew help # run 3 ./gradlew help # run 4 <- steady state ``` Record each wall time. You should see a **decaying curve** that flattens — that flat value is the warm throughput. ### 2. Establish the cold baseline Force a cold JVM and time it: ```bash ./gradlew --stop ./gradlew help --no-daemon # cold JVM, no reuse ``` The **difference** between this cold time and the warm steady-state is the warmup benefit for *your* build. ### 3. Attribute the time Use Gradle's profiling to ensure you're measuring the right thing: - `--profile` writes an HTML report breaking down **configuration vs. task execution** time. - A **build scan** (`--scan`) gives a hosted timeline including daemon and performance details. If warmup is the factor, the savings show up in the always-run phases (configuration, snapshotting) rather than in cached task execution. ### 4. Control the experiment - Same inputs every run; no source changes between runs. - Discard the **first** run if it also populates caches (separate effect). - Quiesce the machine (no heavy background load). - Repeat a few times and take medians — wall-clock timing is noisy. ### Interpreting results For **short** builds, warm vs. cold can differ substantially (warmup is a large relative share). For **long** builds, the difference shrinks because warmup is amortized over the run. So the teammate's claim is **build-dependent** — measuring tells you which regime you're in instead of arguing.

  • Why discard the first run when measuring warmup?
    The first run can also populate the build cache, configuration cache, and OS file cache — effects separate from JVM warmup. Discarding it isolates the JIT/class-load warmup signal from cache-population noise.
  • What tool attributes the saved time to a build phase?
    Gradle's `--profile` HTML report (or a build scan via `--scan`) breaks time into configuration vs. task execution, confirming whether savings are in always-run build logic rather than cached task work.

saying these in an interview costs you the question

  • Comparing a single warm run to a single cold run — wall-clock timing is noisy; use repeats and medians.
  • Forgetting to control inputs, so cache population or source changes contaminate the comparison.
  • Concluding 'daemon doesn't help' from a long build without recognizing warmup is amortized there.

context

resolving links…