Nixpkgs Architecture Team | 233 Members | |
| https://github.com/nixpkgs-architecture, weekly public meetings on Wednesday 15:00-16:00 UTC at https://meet.jit.si/nixpkgs-architecture | 53 Servers |
| Sender | Message | Time |
|---|---|---|
| 19 Dec 2022 | ||
| Oh this shouldn't be required to benchmark this | 21:09:54 | |
| my rationale was that I wanted to try multiple filesystems, and since my regular FS and the Nix Store are the only two I have on this box I was just trying both of them out. | 21:10:47 | |
| but yeah agreed | 21:10:50 | |
You only need to check the performance of builtins.readDir, nothing else. So essentially just a nix-instantiate --eval -E 'builtins.seq (builtins.readDir ./.) null should be enough (no need to test the sharding even) | 21:11:19 | |
* You only need to check the performance of builtins.readDir, nothing else. So essentially just a nix-instantiate --eval -E 'builtins.seq (builtins.readDir ./.) null' should be enough (no need to test the sharding even) | 21:11:41 | |
In reply to @infinisil:matrix.org(offline again) | 22:11:58 | |
| I made some significant changes to https://github.com/nixpkgs-architecture/simple-package-paths/pull/20 btw | 22:20:06 | |
| I also think the tool should be done in a separate repository, rather than https://github.com/nixpkgs-architecture/simple-package-paths/pull/22 | 22:21:30 | |
| I'll probably move that to github.com/nixpkgs-architecture/nix-spp or so (repository/CLI name ideas appreciated) | 22:23:21 | |
| 20 Dec 2022 | ||
| I did the million directories test and it ran in exactly the same amount of time with and without the patch. I think my filesystem on OSX must support some equivalent of | 15:15:40 | |
So that patch in terms of optimization of readDirs is most likely just going to help filesystems that require explicit lstat on single files | 15:17:07 | |
| In any case I'm pretty sure my performance issues were more about encryption of the Nix store. Still, I think being able to check individual files' types is useful ; but I'd say from a practical standpoint this isn't relevant to the "simple package paths" RFC | 15:21:52 | |
| Can you post a comment in https://github.com/nixpkgs-architecture/simple-package-paths/issues/17? | 15:23:01 | |
| Yeah. Good news really I think | 15:25:38 | |
growpotkin ( Alex Ameen ): Oh hm, we should probably also test against an all-packages.nix file | 15:26:26 | |
So you now measured that readDir is as fast on Darwin as on Linux, but it might still be that readDir for sharding is much slower than an all-packages.nix file doing the same | 15:27:31 | |
| I would say that yeah - in general, Nix is going to be slower reading a large number of small files rather than a single large file; but I'd also argue that sharding doesn't necessarily mean that we're reading more files. | 15:29:42 | |
| Nix should still only read in and evaluate packages which are referred to as inputs to targets being built/installed or otherwise forced to values. Creating the package set does not cause those files to be read unless their attribute names are the result of processing the files. | 15:31:07 | |
| so:
Doesn't necessarily cause anything other than the closure of
| 15:38:10 | |
| * so:
Doesn't necessarily cause anything other than the closure of
| 15:38:55 | |
| * so:
Doesn't necessarily cause anything other than the closure of
| 15:39:23 | |
in order to pull that off there are a few changes that need to be made to package names - relatively few; but I ran into them even in my shard-test repo. | 15:40:24 | |
| for example these names throw a wrench in the approach I'm recommending:
Because on case insensitive filesystems you can't have 4 directories with those names. Instead you'd have to either make some encoding for dirnames or write the package name to some file ( which would be slow as sin ). In the
| 15:45:14 | |
| Ohh interesting, I haven't consider case-insensitive filesystems | 15:47:29 | |
| * Ohh interesting, I haven't considered case-insensitive filesystems | 15:47:54 | |
| honestly my recommendation is "package names must be lowercase", "package names must not contain '.'", and "package names must not contain spaces or other non-graphical characters" | 15:48:17 | |
| I guess we'd just need an additional check in nixpkgs that disallows attributes that would be the same without case-sensitivity | 15:48:37 | |
it is potentially useful to align with Nix's character restrictions for installables here; but not immediately necessary or useful ( aside from simplifying handling of legacyPackages and nix run type stuff ). | 15:49:22 | |
I don't see why . should not be allowed | 15:50:04 | |
| Ascii might be a good restriction too | 15:50:30 | |