skip to content

Parallelism And Daemon Performance

4 roadmaps35 questions

Making a build use the machine it runs on: parallel project execution, worker limits, project isolation, and a warm daemon. Interviewers ask because these settings are cheap to change and usually untouched.

on this pageshow

explore

questions

page 2 of 2

Mechanically, how does a retained VFS speed up Gradle's up-to-date checks compared with a cold snapshot?

level: seniorimportance: should knowfreq 28%

basics

~20 s

Up-to-date checks compare current input/output hashes to the last build's. A cold VFS re-stats and re-hashes every input; a retained VFS reuses cached hashes for unchanged files and only re-snapshots paths the OS reported changed.

open as a page

You enabled file system watching but warm builds aren't faster and you see 'retained 0 files' — how do you systematically troubleshoot it?

level: seniorimportance: should knowfreq 22%

basics

~20 s

Confirm the daemon is reused (stable JVM args, not --no-daemon), the workspace is on a local supported filesystem, and on Linux the inotify quota is high enough. Use org.gradle.vfs.verbose to see retained vs. invalidated counts.

open as a page

What performance benefits does Project Isolation deliver, and what are the trade-offs of adopting it today?

level: middleimportance: nice to knowfreq 20%

basics

~10 s

It speeds up large multi-project builds via parallel and incremental configuration, so only changed projects reconfigure. The trade-off: it's incubating, needs cross-project access removed, and not all plugins are compatible.

open as a page

Explain how HotSpot's tiered JIT compilation produces the warmup curve a Gradle daemon experiences, and why a long-lived daemon eventually reaches peak throughput.

level: seniorimportance: nice to knowfreq 22%

basics

~10 s

HotSpot first interprets, then C1-compiles hot methods quickly, gathers profiles, and finally C2-compiles the hottest methods to highly optimized code. Over several builds the daemon converges on this fast C2 code, reaching peak speed.

open as a page

How would you choose a value for org.gradle.workers.max for a memory-heavy multi-module build, and how do you validate the choice empirically?

level: seniorimportance: nice to knowfreq 20%

basics

~20 s

Start near the core count, but cap it so workers × per-fork/daemon heap fits available RAM. Then sweep a few values (e.g. 2/4/6/8), measure wall-time and GC/OOM with build scans, and keep the smallest value that gives near-peak speed.

open as a page

showing 31–35 of 35