| 7 Aug 2021 |
 tomberek |
hrm... that would be super noisy with nixpkgs | 20:49:51 |
| tomberek | * I think we can add an informative output any time there is no flake.lock for an input flake.
* Flake 'myflake' is not locked
* Updated 'myflake': ASDSAD -> ASDSADA"
| 21:06:48 |
| 8 Aug 2021 |
 Las | Wasn't Nix going to support storing Git repositories natively in /nix/store? I seem to remember an issue about it on https://github.com/NixOS/nix. | 15:24:01 |
|  Kha joined the room. | 15:27:54 |
| tomberek | #1006 has discussion ^^^^ | 15:31:47 |
| Las | Thanks! | 15:32:33 |
|  infinisil removed their profile picture. | 22:48:52 |
| 9 Aug 2021 |
 manveru | i wonder if there's even a way to fix https://github.com/NixOS/nix/blob/master/src/libexpr/symbol-table.hh#L79 easily... maybe using std::unordered_set::count first to find the key without too many allocations and making life a bit easier for our GC? But of course that adds CPU overhead by doing the lookup twice... | 08:47:22 |
 Mic92 | manveru: what do you save this way? | 12:13:14 |
| Mic92 | * manveru: what do you safe this way? | 12:13:22 |
| Mic92 | Ah constructing a string. | 12:13:37 |
| manveru | yeah :) | 12:13:43 |
| manveru | would need to bench to see if it's worth it... just stumbled over it when reading the code | 12:14:08 |
| Mic92 | I was also trying to optimize the very same code yesterday | 12:14:25 |
| Mic92 | There are different hash table implementations one can use. | 12:14:41 |
| Mic92 | llvm also has a hash set specific to symbols that allocates strings within the hash table to save memory. | 12:15:08 |
| Mic92 | I guess a count should be cheaper than a malloc but maybe you can do the benchmark. | 12:16:08 |
| manveru | well, i'd imagine a count won't allocate anything in the GC, so it should help for stuff like haskell.nix which has a ton of symbols afaik... | 12:20:46 |
 andi- | Why count over find? Do you fear the allocation an allocator might produce? count could probably be more costly than find that (should?) return on the first positive match. | 12:40:15 |
| Mic92 | There are also other interesting hash tables. For example for pointer to pointer maps, a dense hash map is better. | 14:29:57 |
| andi- | We probably want to store only the ptr but sort/bucket them by a hash for the string value to make lookups fast(er)? | 15:54:12 |
|  dadada (they/them) changed their display name from dadada to dadada (they/them). | 15:59:41 |
| andi- | I did a very unscientific benchmark of one version that uses unique_ptr and allocates only for new elements (AFAICT) and one that is basically what we have right now: https://quick-bench.com/q/BI8_-Nfg9dYrGBEwKR-0xm1QKw4 | 17:19:38 |
| andi- | 
Download BI8_-Nfg9dYrGBEwKR-0xm1QKw4.png | 17:19:54 |
| andi- | If you move the constructor / destructor of the table out of the loop it is 200 / 1100 in favor of the ptr approach. | 17:23:23 |
| andi- | The sad story is that this doesn't really seem to have an effect in practice :( It is +- 0.02 sec difference when evaling the Firefox test. | 17:47:32 |
| manveru | andi-: i'd love to try that with something a bit more GC heavy to see memory impact... i didn't expect much CPU difference | 18:54:27 |
| andi- | But those Symbols aren't tracked by the GC? Otherwise we should set an allocator for them. | 18:55:10 |
| manveru | i don't know how C++ works unfortunately :( | 18:55:47 |
| andi- | They are allocated once and stay there until the process terminates | 18:56:16 |
