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

A flake-based NixOS configuration that pulls in a large module set can spend a long stretch on nixos-rebuild before any derivation starts building. Nix evaluation is single-threaded, the entire configuration is re-evaluated on every rebuild, and wall-clock time blends evaluation, input fetching, and build planning into one number.

The goal is to measure before optimizing: confirm whether evaluation is actually the dominant phase before restructuring imports, trimming flake inputs, or reaching for parallel evaluation tooling. On a recent stable release (NixOS 25.05 with Nix 2.24 or newer, for example), the evaluator exposes statistics and tracing instrumentation, but flag names and output formats have shifted across versions, so the supported method on current Nix needs confirmation.

Two constraints complicate attribution: locked inputs still trigger full re-evaluation of the module system, and hardware differences such as single-core speed and store size can dominate comparisons between machines.

• Which supported flags or counters on current Nix reliably separate evaluation time from fetch and build time for a flake toplevel?
• Can per-module or per-import cost be attributed inside the module system, or is only aggregate evaluation data available?
• Below what measured share of total rebuild time do import-trimming optimizations stop being worth the churn?