| 26 May 2026 |
 Maxisthespy | Is there a nixpkgs / evaluator performance group I am interested in helping improve performance but don’t want to duplicate work/ do things wrong | 20:52:59 |
 llakala | I've been working for the last ~month with emilazy informally on nixpkgs performance | 20:56:45 |
| llakala | other than that, not that I know of | 20:56:51 |
| llakala | xovidium is responsible for a lot of the recent improvements to cppnix | 20:57:28 |
 infinisil | And @adisbladis also has a good eye for Nix performance, has made some improvements in Nixpkgs | 20:58:07 |
| infinisil | (I'd love to help out more too but I'm spread too thin for that) | 20:58:33 |
| llakala | the other merger of my PRs! | 20:58:35 |
| llakala | Redacted or Malformed Event | 20:59:29 |
| llakala | (oops I confused you and alyssa, damn names) | 20:59:46 |
 isabel | on a similar note there are repos tracking the progress of evaluations speeds across nix versions. which will also happens to track nixpkgs eval perf improvements | 21:00:12 |
| isabel | https://github.com/blahai/nixpkgs-eval-benchmarks | 21:00:14 |
| llakala | generally I'm happy to say that a lot of the low hanging fruit in nixpkgs has been improved | 21:01:27 |
| llakala | there are still lots of ideas and plans I have | 21:02:03 |
| llakala | but it's a lot harder to find small-diff, no-rebuilds, big-impact changes than it was before | 21:04:02 |
| llakala | a lot of the plans I still have require more collaboration | 21:05:00 |
| isabel | its noticeable! the repo i sent has a commit titled "holy shit they made nixpkgs fast" and i bring this up since your prs were the reason they recently did a new eval batch. so your work is certainly appreciated | 21:05:33 |
| llakala | as an example, python packages do a very stupid thing currently where they all add python to the build inputs, and then deduplicate the inputs with lib.unique, which is O(n²) | 21:08:26 |
| llakala | this happens multiple times when a python package depends on another | 21:09:30 |
| llakala | see https://github.com/NixOS/nixpkgs/blob/b57eb40ea7694d823e3e12b0791090ac0e4256ca/pkgs/development/interpreters/python/mk-python-derivation.nix#L384 and https://github.com/NixOS/nixpkgs/blob/7cd5d7ee7e67501dc31ba3ab4c27d4d5fced6bca/pkgs/development/interpreters/python/python-packages-base.nix#L136 | 21:12:20 |
| llakala | * see here and here | 21:12:50 |
| infinisil | unsafeDiscardStringContext removes all context, you're left with a normal string. unsafeDiscardOutputDepencency only removes the string context refering to the output of derivations, not the derivations themselves. This means if you interpolate it, Nix will instantiate the derivation tree, but not build them. This can be used for e.g. creating a script that calls nix-build ${unsafeDiscardOutputDependency hello.drvPath} | 21:14:15 |
| llakala | hardening logic is also duplicated between the builder and mkDerivation, and the mkDerivation side accounts for a meaningful amount of eval time - but to fix that, I need to understand what's happening on the builder side more | 21:15:24 |
|  Jeremy Fleischman (jfly) joined the room. | 21:15:52 |
| llakala | and we currently iterate through all build inputs to ensure that they're of the right type to give a pretty error message - ideally this would be moved to cppnix, since nix itself should still be able to get position info with drvAttrs to give the nice error | 21:17:51 |
| llakala | I've also got stuff like https://github.com/NixOS/nixpkgs/issues/522442 that will make a big improvement, but I need feedback from stdenv maintainers on which way i should do it | 21:19:46 |
| llakala | so perf is getting better, the pace is just probably going to slow down | 21:21:05 |
 Matt Sturgeon | Thanks. That adds some clarity, though I'm still a little fuzzy.
I'm also unclear how the unsafeDiscardReferences attribute fits into the picture. When I tested, I found that setting unsafeDiscardReferences.out = true still built derivations I referenced in structured drv-attrs.
| 21:22:31 |
| llakala | the most helpful thing other people can do is provide their expertise on niche areas of the codebase, review PRs, and send their own improvements to non-nixpkgs bottlenecks (cppnix, lix, home-manager, flake-parts, etc) | 21:24:48 |
| llakala | * | 21:25:05 |
 Sergei Zimmerman (xokdvium) | In reply to @llakala:matrix.org
as an example, python packages do a very stupid thing currently where they all add python to the build inputs, and then deduplicate the inputs with lib.unique, which is O(n²) I’ve fixed similar things in the past with genericClosure in flutter | 21:26:05 |
