| 10 Dec 2025 |
 piegames | yes, but the issue is, what is your cache key? | 17:25:37 |
| piegames | inode number and ctime might be our best bet | 17:28:31 |
| piegames | but in terms of cachable data structures, bytecode gives us that for free | 17:29:02 |
| piegames | * but in terms of cachable data structures, bytecode gives us that bit for free | 17:29:28 |
 Charles | In reply to @piegames:flausch.social
yes, but the issue is, what is your cache key? What do other interpreters do? | 17:31:54 |
| piegames | I don't think any other interpreters have comparable performance requirements for parsing | 17:33:30 |
| piegames | if there constraints weren't as tight we could just go content-addressed and use a hash | 17:33:43 |
 Qyriad | bytecode is our::Qyriad's long term goal | 17:35:18 |
| Qyriad | or really whenever someone pays us for it | 17:35:25 |
| Qyriad | * or whenever someone pays us for it | 17:35:36 |
| piegames | I think browser engines have sufficient control over their baseline caching pipelines and what data changes when that they can probably just track what changes easily, but I'm guessing here | 17:36:08 |
 KFears (burnt out) | In reply to @piegames:flausch.social
no, parsing is super fast, mostly thanks to horrors, it's just that Nixpkgs is 3.6MLOC over 40k files and every single NixOS eval loads a good chunk of that, realistically multiple times. The main issue is that caching was never a thought in the architecture and adding it afterwards is really tricky I don't know how many of those lines are going to be actually parsed (now I wish I could somehow learn that into), but assuming 20% utilization (that doesn't sound too unreasonable, considering that my desktop has 2k packages, but there's a lot of re-evals due to module system, splicing, package variations etc.), that doesn't sound too terrible? Like, other interpreters and compilers probably deal with 700k LOC codebases. How do they deal with that? | 17:36:40 |
| piegames | I'm dreaming of tackling it for 2.96 really | 17:36:58 |
| piegames | I already have a half-working prototype from a year ago, horrors had one too, and we should soon have all the parts together for doing it | 17:37:37 |
| piegames | main question is whether to do it in C++ or to block it on RPC and do it in Rust | 17:37:53 |
 helle (just a stray cat girl) | please don't do it in C++ | 17:38:13 |
| helle (just a stray cat girl) | we don't want to have to migrate that later on | 17:38:26 |
| Qyriad | we would either block it on RPC, or bind it to existing libexpr over C bindings. the refactoring necessary for libexpr to use a bytecode interpreter over C ABI would be like half the battle for the decoupling we need to do anyway | 17:40:46 |
 Sergei Zimmerman (xokdvium) | FWIW v8 uses the source code hash as the cache key https://github.com/v8/v8/blob/427f7cce6d69a2d6ce113200e8dcc1151765058c/src/snapshot/code-serializer.cc#L820-L834 | 17:41:09 |
| Sergei Zimmerman (xokdvium) | So the closest thing would be to hash .nix files -> cached bytecode -> cached optimizer -> .... -> profit? | 17:42:32 |
| piegames | that's the goal yes | 17:44:02 |
| piegames | unclear about profit though | 17:44:06 |
 Rutile (Commentator2.0) feel free to ping | Do we understand the overall parsergoal correctly as "use the fastest parser available, errors be damned and if it fails reparse with a good error handling one performance be damned"? | 17:44:16 |
| piegames | unclear. Having a single fast parser with decent error handling and performance would be nice | 17:44:52 |
| KFears (burnt out) | In reply to @qyriad:katesiria.org
we would either block it on RPC, or bind it to existing libexpr over C bindings. the refactoring necessary for libexpr to use a bytecode interpreter over C ABI would be like half the battle for the decoupling we need to do anyway I obviously don't participate in development so my voice matters little, but doing C ABI jumps sounds miserable | 17:45:11 |
| Qyriad | We will need C interop for many parts of the codebase one way or another | 17:45:37 |
| Qyriad | However, we are in the very lucky position that we don't need that ABI to be stable | 17:46:09 |
| Qyriad | Which helps a lot | 17:46:25 |
| piegames | yes, that's why doing it in Rust will mean interop via RPC and subprocesses (which we want anyways) | 17:46:29 |
| Sergei Zimmerman (xokdvium) | That's the hard part too. I imagine bytecode to not be so compact so that serialising it and persisting would have a big overhead. Needs a policy and profiling to see which code is worth caching at all | 17:46:35 |
