# A look at NixOS/Nixpkgs evaluation times over the years
**URL:** https://discourse.nixos.org/t/a-look-at-nixos-nixpkgs-evaluation-times-over-the-years/65114
**Category:** Development
**Created:** [June 2, 2025, 1:37pm UTC](https://discourse.nixos.org/t/a-look-at-nixos-nixpkgs-evaluation-times-over-the-years/65114 "2025-06-02T13:37:58Z")
**Posts on this page:** 19
**Page:** 2
### Author:  [@hexa](https://discourse.nixos.org/u/hexa)
#### Post date: [June 11, 2025, 1:59am UTC](https://discourse.nixos.org/t/a-look-at-nixos-nixpkgs-evaluation-times-over-the-years/65114/22 "2025-06-11T01:59:22Z")
The option count follows the general trend, but shows none of the spikes.
> **csv data**
>
> ```
> Release,Option count
> 15.09,3373
> 16.03,3828
> 16.09,4507
> 17.03,5445
> 17.09,6111
> 18.03,6765
> 18.09,7617
> 19.03,8416
> 19.09,9439
> 20.03,10096
> 20.09,11257
> 21.05,13020
> 21.11,15003
> 22.05,16306
> 22.11,18170
> 23.05,19981
> 23.11,21733
> 24.05,23902
> 24.11,25682
> 25.05,28444
> ```
---
### Author:  [@Profpatsch](https://discourse.nixos.org/u/Profpatsch)
#### Post date: [June 11, 2025, 12:29pm UTC](https://discourse.nixos.org/t/a-look-at-nixos-nixpkgs-evaluation-times-over-the-years/65114/23 "2025-06-11T12:29:35Z")
I’m pretty sure since we strictly have to merge all options before starting to evaluate the actual config object, this is the biggest linear factor we have in nixpkgs. Even if we figure out the spikes, the general linear trend will continue.
---
### Author:  [@Sigmanificient](https://discourse.nixos.org/u/Sigmanificient)
#### Post date: [June 11, 2025, 12:42pm UTC](https://discourse.nixos.org/t/a-look-at-nixos-nixpkgs-evaluation-times-over-the-years/65114/24 "2025-06-11T12:42:40Z")
Can you share how did you generate the graph? Using the `channels.nixos.org` option json, I only see `22118` on nixos-unstable, `21972` on 25.05, … 🤔
---
### Author:  [@hexa](https://discourse.nixos.org/u/hexa)
#### Post date: [June 11, 2025, 1:02pm UTC](https://discourse.nixos.org/t/a-look-at-nixos-nixpkgs-evaluation-times-over-the-years/65114/25 "2025-06-11T13:02:38Z")
```nix
release:
let
pkgs = import (fetchTarball "https://github.com/NixOS/nixpkgs/archive/${release}.tar.gz") {};
lib = pkgs.lib;
moduleList = import "${pkgs.path}/nixos/modules/module-list.nix";
configEval = import "${pkgs.path}/nixos/lib/eval-config.nix" {
system = "x86_64-linux";
modules = moduleList;
};
in
builtins.length (map (opt: opt.name) (lib.optionAttrSetToDocList configEval.options))
```
```auto
$ nix eval --impure --expr '(import ./option-count.nix) "nixos-25.05"'
28471
```
---
### Author:  [@rnhmjoj](https://discourse.nixos.org/u/rnhmjoj)
#### Post date: [June 11, 2025, 1:05pm UTC](https://discourse.nixos.org/t/a-look-at-nixos-nixpkgs-evaluation-times-over-the-years/65114/26 "2025-06-11T13:05:32Z")
The solution to the growing number of module is clear to me: we have to mandate all modules to have an `enable` option as an entry point, and only import and evaluate them if they are enabled.
Existing modules loaded that do stuff unconditionally should be rewritten and enabled explicitely, only some exceptions for very basic setup should remain that way.
---
### Author:  [@Sigmanificient](https://discourse.nixos.org/u/Sigmanificient)
#### Post date: [June 11, 2025, 1:19pm UTC](https://discourse.nixos.org/t/a-look-at-nixos-nixpkgs-evaluation-times-over-the-years/65114/27 "2025-06-11T13:19:38Z")
Thanks! A bit off-topic, but i wonder where this 7k options come from! I see a lot of `_module` present in the list generated form the nix expr that aren’t present in the `options.json.br` of the release
---
### Author:  [@aanderse](https://discourse.nixos.org/u/aanderse)
#### Post date: [June 11, 2025, 2:02pm UTC](https://discourse.nixos.org/t/a-look-at-nixos-nixpkgs-evaluation-times-over-the-years/65114/28 "2025-06-11T14:02:44Z")
yes, not evaluating all modules is a great idea
we have some work to do to get there, though
the pam module is a good example of the work we need to do - the pam module references a ton of other modules
it would be nice if instead the other modules reference pam
---
### Author:  [@Infinisil](https://discourse.nixos.org/u/Infinisil)
#### Post date: [June 11, 2025, 2:15pm UTC](https://discourse.nixos.org/t/a-look-at-nixos-nixpkgs-evaluation-times-over-the-years/65114/29 "2025-06-11T14:15:59Z")
Reference to a previous issue about this:
>
>
> I'm opening this issue to track some things I've done relating to the continuous… slowdown of nixos evaluation performance over time.
>
> My system takes 13 seconds to evaluate (\`nix-instantiate '\' -A system\`), which is too long!
>
> \## What I've done
> \### Measurements
> commit (release): instantiation time for demo.nix (\`time nix-instantiate \`\[test.nix\](https://gist.github.com/d7a0b176d11d824959c33a324c651e78)\` -A system\`, number of options (\`cat $(nix-build --no-out-link nixos/release.nix -A options)/share/doc/nixos/options.json | jq 'keys\[\]' -r | wc -l\`), number of modules (\`nix-instantiate --eval -E 'builtins.length (import nixos/modules/module-list.nix)'\`)
>
> a6caed56607d42b9168c3f1054e7d5913060076f (19.03): 2.74, 7630, 887
> 37694c8cc0e9ecab60d06f1d9a2fd0073bcc5fa3 (18.09): 2.40, 6937, 831
> c8c521f0c03189fd604247e2b2bbe4ab7081968f (18.03): 2.25, 6280, 772
> 3ba3d8d8cbec36605095d3a30ff6b82902af289c (17.09): 1.62, 5741, 737
> 2c1838ab99b086dccad930e8dcc504b867149a0c (17.03): 1.22, 5114, 669
> 52ef8b0d0d66055e799325f0b65d4ecb30f44e49 (16.09): 0.73, 4234, 590
> dda40aa8d18c836cecf64742ace96e14662afdc6 (16.03): 0.65, 3624, 535
> cc7c26173149348ba43f0799fac3f3823a2d21fc (15.09): 0.62, 3131, 493
> 770822493e3962d795739fafd522e771bfe06e3d (14.12): 0.60, 2451, 407
>
> module count has increased by 118%
> option count has increased by 211%
> average option count per module has increased from 6.0 to 8.6
> time has increased by 356%
>
> \### Turning off the options manual generation
> I was hoping that the reason for the regression is due to all options being evaluated strictly, so here's \[my branch\](https://github.com/Infinisil/nixpkgs/commit/2050fcdd152af5fce2c93cc2a0de3eaa3be55d71) (probably could've just turned off the manual but oh well). Results: Decreases evaluation time by a constant of ~1 second, so my system now only takes 12 seconds.. Not good enough. See branch for a bit more info.
>
> \### Alternatively, earlier, offloading option generation to build time
>
> Branch \[here\](https://github.com/Infinisil/nixpkgs/commit/7f82ce2f88ae7c1e4a5ea09e0d6d45cb6c229112). Results: Mostly failed, recursive Nix doesn't work very well and it brings a lot of limitations with it. See branch for a bit more info.
>
> \## Theory / Conclusion
>
> Being out of time for now, I feel like the problem is a combination of:
> \- The \`enable\` options (and similar ones). These \`enable\` options are defined for every module and they need to be evaluated regardless of whether you use the module or not, so this adds up with the ~1110 \`enable\` options we have in 19.03, and ever increasing
> \- The module files itself. This ever increasing \[list of modules\](https://github.com/NixOS/nixpkgs/blob/master/nixos/modules/module-list.nix) to include by default means that Nix needs to parse and evaluate all of them, which of course takes an increasing amount of time.
>
> So this would also mean that the number of options a module defines has only very little influence on evaluation time (in contrast to what I've thought and told other people for some time now)! Of course the manual penalty of 1s is still there, but that's almost negligible.
>
> \## Future Work
>
> \- Do some proper profiling with NIX\_COUNT\_CALLS=1 and/or NIX\_SHOW\_STATS=1
> \- Set up an automated way to track evaluation time for NixOS evaluation (maybe that already exists?)
> \- Now that we have the better cross compilation, how much worse is the performance due to that?
>
> \# Related
>
> \- The gist by @edolstra for a potential future Nix version with support for modules that would be fast by design: https://gist.github.com/edolstra/29ce9d8ea399b703a7023073b0dbc00d
> \- Somewhat related, a previous grave performance regression: https://github.com/NixOS/nixpkgs/issues/8152
>
> \# Pings
>
> @edolstra @nbp @Profpatsch @rycee @aanderse @Ekleog @Ericson2314
---
### Author:  [@edolstra](https://discourse.nixos.org/u/edolstra)
#### Post date: [June 11, 2025, 2:55pm UTC](https://discourse.nixos.org/t/a-look-at-nixos-nixpkgs-evaluation-times-over-the-years/65114/30 "2025-06-11T14:55:55Z")
Or minimize the list of modules, as proposed here: [[RFC 0022] Minimal module list by edolstra · Pull Request #22 · NixOS/rfcs · GitHub](https://github.com/NixOS/rfcs/pull/22)
Having an `enable` option still requires the module to be parsed and (to some extent) evaluated, so it’s not a scalable approach.
---
### Author:  [@aanderse](https://discourse.nixos.org/u/aanderse)
#### Post date: [June 11, 2025, 3:03pm UTC](https://discourse.nixos.org/t/a-look-at-nixos-nixpkgs-evaluation-times-over-the-years/65114/31 "2025-06-11T15:03:22Z")
ah… i misinterpreted what @rnhmjoj had written…
i thought he meant what you said 🙂 yes, a minimal module list would benefit us in several ways 👍
---
### Author:  [@lassulus](https://discourse.nixos.org/u/lassulus)
#### Post date: [June 11, 2025, 3:05pm UTC](https://discourse.nixos.org/t/a-look-at-nixos-nixpkgs-evaluation-times-over-the-years/65114/32 "2025-06-11T15:05:32Z")
>
>
> related: https://github.com/NixOS/nixpkgs/issues/137168
>
> This adds:
> \- a \`mini…mal.nix\` file containing a list of 185 modules that are required for building the \`toplevel\` of an (almost) empty nixos configuration.
> \- a test that builds a minimal nixos system to ensure that the minimal.nix doesn't miss any modules.
>
> This is only the first step and further work is required in order to improve the experience using nixosMinimal, like:
> \- refactoring existing modules to explicitly import their dependency modules
> \- adding CI checks to assure modules declare imports correctly
>
> cc @roberth
>
>
>
> \## Things done
>
>
>
> \- Built on platform(s)
> - \[\] x86\_64-linux
> - \[\] aarch64-linux
> - \[\] x86\_64-darwin
> - \[\] aarch64-darwin
> \- For non-Linux: Is sandboxing enabled in \`nix.conf\`? (See \[Nix manual\](https://nixos.org/manual/nix/stable/command-ref/conf-file.html))
> - \[\] \`sandbox = relaxed\`
> - \[\] \`sandbox = true\`
> \- \[\] Tested, as applicable:
> - \[NixOS test(s)\](https://nixos.org/manual/nixos/unstable/index.html#sec-nixos-tests) (look inside \[nixos/tests\](https://github.com/NixOS/nixpkgs/blob/master/nixos/tests))
> - and/or \[package tests\](https://github.com/NixOS/nixpkgs/blob/master/pkgs/README.md#package-tests)
> - or, for functions and "core" functionality, tests in \[lib/tests\](https://github.com/NixOS/nixpkgs/blob/master/lib/tests) or \[pkgs/test\](https://github.com/NixOS/nixpkgs/blob/master/pkgs/test)
> - made sure NixOS tests are \[linked\](https://github.com/NixOS/nixpkgs/blob/master/pkgs/README.md#linking-nixos-module-tests-to-a-package) to the relevant packages
> \- \[\] Tested compilation of all packages that depend on this change using \`nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD"\`. Note: all changes have to be committed, also see \[nixpkgs-review usage\](https://github.com/Mic92/nixpkgs-review#usage)
> \- \[\] Tested basic functionality of all binary files (usually in \`./result/bin/\`)
> \- \[25.05 Release Notes\](https://github.com/NixOS/nixpkgs/blob/master/nixos/doc/manual/release-notes/rl-2505.section.md) (or backporting \[24.11\](https://github.com/NixOS/nixpkgs/blob/master/nixos/doc/manual/release-notes/rl-2411.section.md) and \[25.05\](https://github.com/NixOS/nixpkgs/blob/master/nixos/doc/manual/release-notes/rl-2505.section.md) Release notes)
> - \[\] (Package updates) Added a release notes entry if the change is major or breaking
> - \[\] (Module updates) Added a release notes entry if the change is significant
> - \[\] (Module addition) Added a release notes entry if adding a new NixOS module
> \- \[\] Fits \[CONTRIBUTING.md\](https://github.com/NixOS/nixpkgs/blob/master/CONTRIBUTING.md).
>
>
>
> \---
>
> Add a :+1: \[reaction\] to \[pull requests you find important\].
>
> \[reaction\]: https://github.blog/2016-03-10-add-reactions-to-pull-requests-issues-and-comments/
> \[pull requests you find important\]: https://github.com/NixOS/nixpkgs/pulls?q=is%3Aopen+sort%3Areactions-%2B1-desc
---
### Author:  [@aanderse](https://discourse.nixos.org/u/aanderse)
#### Post date: [June 11, 2025, 3:51pm UTC](https://discourse.nixos.org/t/a-look-at-nixos-nixpkgs-evaluation-times-over-the-years/65114/33 "2025-06-11T15:51:21Z")
i wasn’t aware of that PR… that is awesome!
> - a `minimal.nix` file containing a list of 185 modules that are required for building the `toplevel` of an (almost) empty nixos configuration.
> This is only the first step and further work is required in order to improve the experience using nixosMinimal
right, an awesome first step! i’m convinced we can go much lower, though - just as a random example
```auto
./programs/seahorse.nix
```
currently i’m building my laptop with under `80` nix modules so we can definitely get there, just takes a bunch of refactoring to cleanly separate modules
very exciting work! thanks so much @DavHau and @lassulus for your efforts! 🚀
* * *
note that in this case i defined “nix module” as the result of `find ./module-path -type f -name *.nix | wc -l`
---
### Author:  [@bartbie](https://discourse.nixos.org/u/bartbie)
#### Post date: [June 11, 2025, 4:30pm UTC](https://discourse.nixos.org/t/a-look-at-nixos-nixpkgs-evaluation-times-over-the-years/65114/34 "2025-06-11T16:30:38Z")
> [@rnhmjoj](#):
>
> an `enable` option as an entry point, and only import and evaluate them if they are enabled
sorry if this is too off-topic, but i thought making `imports` dependent on `config` isn’t possible in the module system since it would cause an infinite recursion?
---
### Author:  [@bme](https://discourse.nixos.org/u/bme)
#### Post date: [June 11, 2025, 4:36pm UTC](https://discourse.nixos.org/t/a-look-at-nixos-nixpkgs-evaluation-times-over-the-years/65114/35 "2025-06-11T16:36:47Z")
Right, but you can use `${modulesPath}/path/to/module.nix` to explicitly import modules. Currently all the modules are imported. The idea here would be to not import them at all. Users would need to explicitly import them.
---
### Author:  [@bartbie](https://discourse.nixos.org/u/bartbie)
#### Post date: [June 11, 2025, 4:40pm UTC](https://discourse.nixos.org/t/a-look-at-nixos-nixpkgs-evaluation-times-over-the-years/65114/36 "2025-06-11T16:40:15Z")
aghh i thought there is/would be a way to do that without explicitly adding paths i just didn’t know, oh well 🤠
---
### Author:  [@rnhmjoj](https://discourse.nixos.org/u/rnhmjoj)
#### Post date: [June 11, 2025, 5:40pm UTC](https://discourse.nixos.org/t/a-look-at-nixos-nixpkgs-evaluation-times-over-the-years/65114/37 "2025-06-11T17:40:46Z")
> [@bartbie](#):
>
> sorry if this is too off-topic, but i thought making `imports` dependent on `config` isn’t possible in the module system since it would cause an infinite recursion?
Yes, importing modules on-demand requires some changes to the module system. I think someone was working on this, but I can’t find a PR. IIRC roberth.
EDIT: I was thinking of this [proof of concept](https://github.com/NixOS/nixpkgs/issues/137168#issuecomment-933019922), but it looks like it never materialised.
---
### Author:  [@junestepp](https://discourse.nixos.org/u/junestepp)
#### Post date: [June 11, 2025, 5:55pm UTC](https://discourse.nixos.org/t/a-look-at-nixos-nixpkgs-evaluation-times-over-the-years/65114/38 "2025-06-11T17:55:02Z")
> [@rnhmjoj](#):
>
> Yes, importing modules on-demand requires some changes to the module system. I think someone was working on this, but I can’t find a PR. IIRC roberth.
>
>
> Allow conditional imports, this is done by always importing and pushing any \`mkI…f\` into the module.
>
> ~~This also allows conditionally importing modules one didn't write. I.e. when using flake, you could toggle them via personal options~~
>
> Certain design decisions are documented in the respective commit bodies.
>
>
> \## Things done
>
>
>
> \- Built on platform(s)
> - \[X\] x86\_64-linux
> - \[\] aarch64-linux
> - \[\] x86\_64-darwin
> - \[\] aarch64-darwin
> \- For non-Linux: Is sandboxing enabled in \`nix.conf\`? (See \[Nix manual\](https://nixos.org/manual/nix/stable/command-ref/conf-file.html))
> - \[\] \`sandbox = relaxed\`
> - \[\] \`sandbox = true\`
> \- \[\] Tested, as applicable:
> - \[NixOS test(s)\](https://nixos.org/manual/nixos/unstable/index.html#sec-nixos-tests) (look inside \[nixos/tests\](https://github.com/NixOS/nixpkgs/blob/master/nixos/tests))
> - and/or \[package tests\](https://github.com/NixOS/nixpkgs/blob/master/pkgs/README.md#package-tests)
> - or, for functions and "core" functionality, tests in \[lib/tests\](https://github.com/NixOS/nixpkgs/blob/master/lib/tests) or \[pkgs/test\](https://github.com/NixOS/nixpkgs/blob/master/pkgs/test)
> - made sure NixOS tests are \[linked\](https://github.com/NixOS/nixpkgs/blob/master/pkgs/README.md#linking-nixos-module-tests-to-a-package) to the relevant packages
> \- \[\] Tested compilation of all packages that depend on this change using \`nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD"\`. Note: all changes have to be committed, also see \[nixpkgs-review usage\](https://github.com/Mic92/nixpkgs-review#usage)
> \- \[\] Tested basic functionality of all binary files (usually in \`./result/bin/\`)
> \- \[25.05 Release Notes\](https://github.com/NixOS/nixpkgs/blob/master/nixos/doc/manual/release-notes/rl-2505.section.md) (or backporting \[24.11\](https://github.com/NixOS/nixpkgs/blob/master/nixos/doc/manual/release-notes/rl-2411.section.md) and \[25.05\](https://github.com/NixOS/nixpkgs/blob/master/nixos/doc/manual/release-notes/rl-2505.section.md) Release notes)
> - \[\] (Package updates) Added a release notes entry if the change is major or breaking
> - \[\] (Module updates) Added a release notes entry if the change is significant
> - \[\] (Module addition) Added a release notes entry if adding a new NixOS module
> \- \[X\] Fits \[CONTRIBUTING.md\](https://github.com/NixOS/nixpkgs/blob/master/CONTRIBUTING.md).
>
> \---
>
> Add a :+1: \[reaction\] to \[pull requests you find important\].
>
> \[reaction\]: https://github.blog/2016-03-10-add-reactions-to-pull-requests-issues-and-comments/
> \[pull requests you find important\]: https://github.com/NixOS/nixpkgs/pulls?q=is%3Aopen+sort%3Areactions-%2B1-desc
---
### Author:  [@purepani](https://discourse.nixos.org/u/purepani)
#### Post date: [June 16, 2025, 7:26am UTC](https://discourse.nixos.org/t/a-look-at-nixos-nixpkgs-evaluation-times-over-the-years/65114/39 "2025-06-16T07:26:59Z")
Since @Mic92 mentioned the flamegraphs in the nightly nix versions, [I decided to make some](https://github.com/purepani/nix-eval-times)!
I decided not to put the logs in the repo since they were too big and I didn’t feel like compressing it, but if you just drop into the devshell and run `uv run nixpkgs-profiler.py`, the logs will be generated.
The flamegraphs are in `outputs/flamegraphs/*.svg`.
Note that you need to drop into the devshell to have the logs generate, since the python script shells out to the nix version in `PATH`, and I was too lazy to create a derivation.
This might have some flake overhead compared to the original graphs, but I doubt it’ll be too big. I haven’t really looked at it at all.
---
### Author:  [@xokdvium](https://discourse.nixos.org/u/xokdvium)
#### Post date: [July 9, 2025, 6:23pm UTC](https://discourse.nixos.org/t/a-look-at-nixos-nixpkgs-evaluation-times-over-the-years/65114/40 "2025-07-09T18:23:20Z")
The memory usage aspect should improve somewhat with nix 2.30 [Nix 2.30.0 released](https://discourse.nixos.org/t/nix-2-30-0-released/66449). Various memory usage optimisations in that release add up to ~25% less memory (only on 64 bit systems) usage for a whole nixpkgs eval.
[Previous page](https://discourse.nixos.org/t/a-look-at-nixos-nixpkgs-evaluation-times-over-the-years/65114.md?page=1)