Slow flake rebuilds: diagnosing whether NixOS evaluation is the real bottleneck

Direct answer

Evaluation is a plausible bottleneck because Nix evaluates the entire module system single-threaded on every rebuild, even with locked inputs. But you must measure it — don't assume. The reliable way on current Nix (2.18+/2.24+/Lix) is to time a pure evaluation of the toplevel derivation path and compare it against the full nixos-rebuild wall-clock time.

How to separate evaluation from fetch and build time

1. Measure pure evaluation time (no fetch, no build planning):

   time nix eval --raw .#nixosConfigurations.<host>.config.system.build.toplevel.drvPath

   This forces the evaluator to produce the toplevel derivation path. It exercises the module system, option merging, and derivation construction — the bulk of evaluation work.

2. Measure the full rebuild dry-run (includes fetch if inputs missing, plus instantiation and build planning):

   time nixos-rebuild dry-build --flake .#<host>

3. Isolate fetch time by repeating both commands with a warm store and locked inputs, then adding --offline to the rebuild:

   time nixos-rebuild dry-build --flake .#<host> --offline

   The difference between the two time runs approximates fetch overhead. What remains in the rebuild after subtracting the nix eval time is instantiation and build planning.

What flags and counters are actually supported

Flag names and stats output have shifted across Nix 2.18, 2.24, and Lix. Do not trust older blog posts. Verify on your machine:

nix --version
nix show-config | grep -i eval
man nix.conf  # check the installed manual for eval-cache and stats options

Commonly available on recent releases:

• NIX_SHOW_STATS=1 — prints aggregate evaluator counters (values allocated, thunks, function calls, GC time, CPU time) to stderr.
• NIX_COUNT_CALLS=1 — counts function calls (heavy output, use sparingly).
• --option eval-cache true — enables the evaluation cache (persisted across invocations when the store allows).

These give aggregate evaluation effort, not a per-module breakdown. They also don't map cleanly to wall-clock time because GC pauses and memory pressure distort the relationship.

Per-module or per-import attribution

Not available as a supported counter. Nix exposes only aggregate evaluator statistics. Fine-grained attribution requires either:

• Import bisection: comment out half your module imports, re-time evaluation, confirm time scales with module count.
• Third-party profiling patches (not upstream).

If you need per-module costs, bisection is the only practical path today.

When import-trimming stops being worth the churn

Heuristic: if measured evaluation time is below roughly 20–30% of total rebuild wall-clock time, restructuring imports and trimming modules is unlikely to pay off relative to the maintenance cost. Target fetch parallelism, substituter configuration, or hardware (single-core speed, store on SSD) instead.

Assumptions and uncertainty

• nix eval of the toplevel drvPath excludes some work nixos-rebuild performs (activation script evaluation, some module finalization). Treat it as a close approximation, not exact.
• Evaluator performance scales strongly with single-core CPU speed, and large /nix/store sizes slow stat-heavy operations. Cross-machine comparisons need normalized conditions.
• Flag availability depends on your exact Nix version (2.18 vs 2.24 vs Lix). On older versions the eval-cache option may be named differently or absent — confirm against the installed manual.

One missing detail that changes the recommendation

What is the output of nix --version on the machine where you're seeing slow rebuilds? If you're on Nix 2.18 or an older Lix release, the stats output format and eval-cache behavior differ, and the measurement approach may need adjustment.