| 21 Nov 2025 |
 helle (just a stray cat girl) | eeeh, ended up with substitue = false and prefetching the one file I needed that was failing with curl and a local nixpkgs pointed at that (trying to find the cache entry for it I was not in the mood for) | 15:02:12 |
 John Ericson | I did that too | 17:10:17 |
| John Ericson | split libcmd into store layer and not store layer parts | 17:10:40 |
|  isabel changed their profile picture. | 18:13:57 |
 Rutile (Commentator2.0) feel free to ping | https://gerrit.lix.systems/c/lix/+/4605
its merged 🎉
| 18:34:13 |
 raitobezarius (DECT: 7248) | I looked and I may have missed it but I still see special cases in libcmd on master. | 18:41:27 |
|  mzero joined the room. | 20:37:43 |
| mzero | did the special casing for small lists get removed? there are still comments that refer to it, but I'm not seeing it in the code (though I could just be missing it) | 20:54:15 |
| raitobezarius (DECT: 7248) | removed, indeed | 20:54:40 |
| raitobezarius (DECT: 7248) | did you notice something problematic for small lists? | 20:54:48 |
| mzero | no, I was just looking at the string changes in the release notes and noticed it. is there any perforce impact from it? I assume lists with exactly 2 elems aren't that common, but I'm still curious. | 20:59:59 |
| raitobezarius (DECT: 7248) | AFAIK, this optimization is noise when we looked | 21:07:47 |
| raitobezarius (DECT: 7248) | Lists with 2 elems are usually pairs in Nixlang | 21:07:58 |
| raitobezarius (DECT: 7248) | Unnamed pairs | 21:08:07 |
 Sergei Zimmerman (xokdvium) | I did research a bit the distribution of list sizes when evaling nixpkgs. Small lists are quite often used, but lists just pale in comparison with attrsets overall | 21:17:12 |
| mzero | name value pairs are so common because of listToAttrs, etc, I wonder if a pair type would actually make a significant perf difference | 21:19:00 |
| Sergei Zimmerman (xokdvium) | A more generic approach could be to have "attrset shapes". Very similar to how v8 optimizes classes with the same layout | 21:20:09 |
| Sergei Zimmerman (xokdvium) | Then names wouldn't need to be stored in the attribute set and function calls could reuse the same memory and not copy anything to a new Env.
(I and Robert Hensing discussed this a bit at some point) | 21:21:57 |
 Qyriad | In reply to @xokdvium:matrix.org
A more generic approach could be to have "attrset shapes". Very similar to how v8 optimizes classes with the same layout benefits of a JIT especially | 21:22:04 |
| Sergei Zimmerman (xokdvium) | Not exactly tho. jit/memory layout are tangential somewhat | 21:22:32 |
| Qyriad | yeah but you can optimize hot shapes | 21:22:56 |
| Sergei Zimmerman (xokdvium) | Yeah. I think python has slots for this kind of thing | 21:23:13 |
| Sergei Zimmerman (xokdvium) | * Yeah. I think python has __slots__ for this kind of thing | 21:23:28 |
| mzero | do you have something I could read about that? I'm curious how it would work. | 21:25:02 |
| Sergei Zimmerman (xokdvium) | Probably staring at prior art in V8? I haven't done that myself, but I'd be curious how they do tracing to find hot shapes | 21:26:04 |
| Sergei Zimmerman (xokdvium) | All of those optimizations are pretty inaccessible without tracing infra :( | 21:27:26 |
| Sergei Zimmerman (xokdvium) | But tracing attrset shapes doesn't exactly depend on function call tracing. Computing a shape fingerprint and having a small hashmap of that could give a rough picture of the frequency. | 21:29:23 |
| Sergei Zimmerman (xokdvium) | So maybe only do this for attrsets smaller than N, compute a hash of symbol table ids, store it a fixed-sized map and count frequency that way. This shouldn't have much of an overhead | 21:30:50 |
| John Ericson | yeah that is in a bitrotted PR | 21:39:29 |
| 22 Nov 2025 |
| helle (just a stray cat girl) | glares at lix/nix/prefetch.cc +118 | 11:47:29 |
