| 27 Jun 2023 |
 figsoda | In reply to @zmitchell:matrix.org
Is there any documentation explaining what's shown while you're building a package e.g. [1/32/39 built, 37 copied (26.4/26.5 MiB), 9.6 MiB DL]? https://github.com/NixOS/nix/issues/3352#issuecomment-584247583 | 22:51:42 |
| 28 Jun 2023 |
 Mic92 | I was thinking about pre-building nixos docs to save eval time when building nixos. | 01:55:28 |
| Mic92 | So same thing as https://github.com/nix-community/nix-index-database but for docs. | 01:55:43 |
 pennae | In reply to @joerg:thalheim.io
I was thinking about pre-building nixos docs to save eval time when building nixos. lazy options is exactly that | 01:58:20 |
| pennae | if you find more places where we can cache things then improvements are definitely welcome, but due to how nixos docs are built we think the next improvement will need flakes (or a similar mechanism for source caching) | 02:04:47 |
|  @zardian:matrix.org joined the room. | 06:32:32 |
| Mic92 | pennae: so you are saying manual generation is already much faster? I haven't benchmarked in a while. | 12:36:56 |
 Pol | I just submitted a PR to fix the nixos manual | 12:43:58 |
| Pol | https://github.com/NixOS/nixos-homepage/pull/1085 | 12:44:01 |
| Pol | But this doesn't have impact on speed | 12:44:13 |
| Pol | Just than the produced html is wrong atm | 12:44:25 |
| Pol | * Just that the produced html is wrong atm | 12:44:36 |
| Pol | This PR actually https://github.com/NixOS/nixpkgs/pull/240327 | 12:45:14 |
| pennae | In reply to @joerg:thalheim.io
pennae: so you are saying manual generation is already much faster? I haven't benchmarked in a while. yeah, when we started out we cut about 40% of eval time off of it. can't remember how much the manual still costs, but it wasn't a substantial fraction or we would've probably gone there too.
(instead we went for the nix evaluator, and if that seems like the easier thing to do ...) | 13:10:43 |
| Mic92 | Redacted or Malformed Event | 13:12:09 |
 nbp | Mic92: Nice password! Thanks for sharing ;) | 13:13:45 |
| pennae | there may still be gains to be had with pre-built docs that aren't necessarily accurate to the current system (turning of nixos docs and adding a cached docs package)? haven't benchmarked in a while either | 13:14:37 |
| Mic92 | How do you measure stuff? | 13:15:24 |
| Mic92 | I find that super hard with nix. | 13:15:32 |
| Mic92 | * How do you profile stuff? | 13:16:05 |
| pennae | mostly just enabling/disabling options and running a lot of clean uncached evals | 13:16:12 |
| Mic92 | Sol It's a bit of a blind flight. NinjaTrappeur added enough instrumentation to nix to get proper stack samples. | 13:17:22 |
| Mic92 | The flamegraphs from that looked way more useful. | 13:17:33 |
| Mic92 | * So, it's a bit of a blind flight. NinjaTrappeur added enough instrumentation to nix to get proper stack samples. | 13:17:55 |
| pennae | back then we also used the older nix profiling suite (NIX_COUNT_CALLS? was that the name?) to find the hot spot, but that didn't really help for much more than that | 13:18:41 |
 @ninjatrappeur:alternativebit.fr | The function-based profiler? | 13:19:01 |
| @ninjatrappeur:alternativebit.fr | andi- improved my not-so-fonctional ebpf profiler. I lost the branch though. | 13:19:28 |
| @ninjatrappeur:alternativebit.fr | * andi- improved my not-so-fonctional ebpf profiler into something pretty fonctional. I lost the branch though. | 13:19:37 |
| @ninjatrappeur:alternativebit.fr | The real issue is the viewer, there's too much information in these traces. We were tracing each and every thunk forcing. | 13:20:06 |
 andi- | In reply to @ninjatrappeur:alternativebit.fr
andi- improved my not-so-fonctional ebpf profiler into something pretty fonctional. I lost the branch though. https://github.com/andir/nix/tree/andir/profiling | 13:21:05 |
