| 28 Jun 2023 |
 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 |
| pennae | fwiw disabling docs on our current system makes no significant difference in eval time, disabling the spit options build adds 30% | 13:22:24 |
 Sandro 🐧 | In reply to @andi:kack.it
https://github.com/andir/nix/tree/andir/profiling Does that improve the existing tracing or add a new one? | 13:30:02 |
| andi- | new one, proper nix-internal call frames and all | 13:30:24 |
| Sandro 🐧 | In reply to @pennae:matrix.eno.space
fwiw disabling docs on our current system makes no significant difference in eval time, disabling the spit options build adds 30% spit options? split options? | 13:30:27 |
| Sandro 🐧 | In reply to @andi:kack.it
new one, proper nix-internal call frames and all you just set NIX_SHOW_TRACE ? | 13:30:46 |
| pennae | split options, yes | 13:30:49 |
| Sandro 🐧 | so setting documentation.nixos.options.splitBuild to false improves eval time if I don't build docs? | 13:47:18 |
| pennae | if you don't build docs setting it to false makes no difference. if you do build docs settings it to false slows down the build by 30% | 13:59:48 |
| Sandro 🐧 | ah, good that we cleared that up | 14:33:17 |
| pennae | if it ever did speed up the build to set it to false we should remove it again :) | 14:37:23 |
| pennae | the infra needed to make it works is a royal pain, if we can get away without it then good riddance | 14:37:43 |
 sterni | do we have an overview of what markdown extensions/custom stuff you can use in the manual somewhere? | 18:04:34 |
| sterni | ah in the obvious place, nice :) | 18:05:17 |
| sterni | pennae: fricklerhandwerk: basically if you do this dynamically you have the same problem, but it is even more complicated; you need to map a value to its definition point and we have no overarching semantics that would fix the meaning of that (e.g. unsafeGetAttrPos would be closest, but also doesn't apply for the reasons pennae outlines). Additionally doing it dynamically means that you have to write a treewalker again and that it'll be slower than statically generating docs | 18:14:28 |
| sterni | I think the RFC should end up in a form where we enforce some kind of convention that means files are nixdoc-able and we can (optionally) also retrieve documentation at runtime in the repl (because it is convenient), but I'd sacrifize the latter if need be—it is a losing battle, since Nix has no module system-like semantics | 18:15:52 |
 fricklerhandwerk | sterni: which RFC do you mean? The one by Johannes Kirschbauer @hsjobeki or some hypothetical one that codifies nixdoc-like semantics? | 18:49:39 |
| sterni | the former | 18:50:09 |
| sterni | and with the current trajectory I think it could be the latter (although I'm a bit fuzzy on what is written down currently) | 18:50:30 |
 @johannes.kirschbauer:scs.ems.host | @sterni if i understand your concerns: yes treewalker would be slow (as slow as evaluation) but at least accurate.
I guess you‘d suggest some limited set of patterns and nesting if you wanted static analysis solution.
And as the RFC got critical mass of sheperds i am thrilled to make progress as soon as @lassulus schedules the first meetups. | 20:48:41 |
| @johannes.kirschbauer:scs.ems.host | Or just use the rfc outcome and build static analysis that can opt-in for dynamic evaluation in edge cases that are not possible with static analysis alone. | 20:52:56 |
