| 19 Jun 2026 |
 alexfmpe | A good deal was probably from me getting confused by lazyness but still | 12:07:04 |
| alexfmpe | In reply to @llakala:matrix.org
i've come to the conclusion that somehow the toposort function has an extreme performance dropoff as the input size reaches a new power of 10
Benchmark 1: nix-instantiate --eval --strict --expr '(import ./benchmark.nix)."999"'
Time (mean ± σ): 244.7 ms ± 4.7 ms [User: 177.6 ms, System: 65.8 ms]
Range (min … max): 238.5 ms … 256.3 ms 25 runs
Benchmark 2: nix-instantiate --eval --strict --expr '(import ./benchmark.nix)."1000"'
Time (mean ± σ): 245.9 ms ± 4.8 ms [User: 177.1 ms, System: 67.6 ms]
Range (min … max): 239.4 ms … 258.7 ms 25 runs
Benchmark 3: nix-instantiate --eval --strict --expr '(import ./benchmark.nix)."1001"'
Time (mean ± σ): 392.6 ms ± 8.8 ms [User: 280.1 ms, System: 108.8 ms]
Range (min … max): 381.2 ms … 411.2 ms 25 runs
same thing happens at 99, 100, and 101
Oddly specific. Maybe some util is called chunking/partioning things into 10 pieces recursively? Then crossing to 10^n+1 territory means one more level of depth | 12:10:02 |
 llakala | you'd think so... but the entire code is two functions, both of which I've read | 12:24:02 |
| llakala | hang on I'll link it | 12:25:22 |
| llakala | https://github.com/NixOS/nixpkgs/blob/805dc355c3c19ceca8b2dc2726d4f0414a64322e/lib/lists.nix#L1246 | 12:26:12 |
| llakala | just toposort and listDfs | 12:26:32 |
| alexfmpe | maybe it happens at the nix impl level? quickly grepping on NixOS/nix gives me nothing obvious though | 12:41:08 |
| alexfmpe | but that's the first thing that comes to mind when things magically get slower with lists of size 10^n+1 | 12:41:38 |
| alexfmpe | or some weird *10 allocation scheme | 12:45:05 |
| alexfmpe | also see nothing interesting when lazy grepping for '\b10\b' around NixOS/nix/lib | 12:46:14 |
| llakala | yeah but this is a deterministic difference | 12:50:45 |
| llakala | it differs in nrPrimops | 12:50:50 |
| llakala | not just real-time perf | 12:50:56 |
 Sergei Zimmerman (xokdvium) | In reply to @alexfmpe:matrix.org
Oddly specific. Maybe some util is called chunking/partioning things into 10 pieces recursively? Then crossing to 10^n+1 territory means one more level of depth Definitely not powers of 10 :) Doubt there’s even anything exponential growth related with a power of 2 (albeit a small suspect, due to std::vector and such) | 12:54:54 |
|  Nuwa changed their profile picture. | 17:41:22 |
| Nuwa removed their profile picture. | 17:41:43 |
| Nuwa set a profile picture. | 17:42:28 |
| Nuwa changed their profile picture. | 17:48:30 |
| Nuwa changed their profile picture. | 18:11:56 |
| 20 Jun 2026 |
|  chronorose joined the room. | 16:30:42 |
|  Turrentianos joined the room. | 17:44:20 |
| Nuwa changed their profile picture. | 19:05:42 |
| 21 Jun 2026 |
|  removed-user joined the room. | 12:25:01 |
|  José Echenique joined the room. | 18:55:19 |
|  tsilvs joined the room. | 21:27:45 |
| tsilvs | Hello, everyone!
I recently started writing my onw NixOS config, and I have a question: How do you usually lint your nix configs?
I noticed there are at least 3 options, probably combinable:
statixnixpkgs-lintbash lint scripts
There is also an ast-grep thing. That may or may not have a .nix syntax support somewhere.
Are there any common (or just practiced by anyone) techniques that allow writing custom AST-query-based rules to, for example, mark "hardcoded" port numbers (not read from a variable) as linting rule violations? | 21:29:41 |
 djacu | There is also deadnix | 21:32:28 |
| tsilvs | AFAIK, it only checks for dead code, right? | 21:33:18 |
| djacu | In reply to @tsilvs:unredacted.org
AFAIK, it only checks for dead code, right? I believe so | 21:34:12 |
| tsilvs | Thank you.
You know anything related to AST queries for Nix configs? | 21:45:27 |
