Nix Hackers | 975 Members | |
| For people hacking on the Nix package manager itself | 206 Servers |
| Sender | Message | Time |
|---|---|---|
| 9 Aug 2021 | ||
| 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 | |
Download BI8_-Nfg9dYrGBEwKR-0xm1QKw4.png | 17:19:54 | |
| 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 | |
| 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 | |
| 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 | |
| But those Symbols aren't tracked by the GC? Otherwise we should set an allocator for them. | 18:55:10 | |
| i don't know how C++ works unfortunately :( | 18:55:47 | |
| They are allocated once and stay there until the process terminates | 18:56:16 | |
| my assumption was that this std::string thing does an allocation that needs to be cleaned up again afterwards | 18:56:26 | |
| I has to be cleaned up but that happens then the entire symboltable goes out of scope | 18:57:01 | |
With C++20 (and GCC 11) we could make use of Heterogeneous lookup for unordered containers (http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0919r3.html) for the lookup using the std::string_view... so far that isn't possible without huge effort AFAICT. | 19:53:17 | |
In reply to @manveru:matrix.orgeven c++ programmers don't know how it works ;-) | 22:46:36 | |
| I am trying to compile
Feels like the | 23:52:00 | |
| 10 Aug 2021 | ||
| 05:51:17 | ||
| What is the point of the GitHub fetcher? I tested the speed difference compared to the Git fetcher and it wasn't so different. | 12:34:16 | |
| I think it performs much worse for big repos | 12:35:20 | |
In reply to @sternenseemann:systemli.orgI tested it on Nixpkgs lol | 12:39:23 | |
| Though perhaps it was because I had already fetched an earlier commit? | 12:39:43 | |
| The github fetcher is way faster than git. | 12:42:25 | |
| Often it's even faster in cases where git can do an incremental fetch. | 12:43:18 | |
In reply to @pamplemouss_:matrix.orghave you tried llvmPackages_11.libcxxStdenv? | 12:44:42 | |
In reply to @niksnut:matrix.orgDo you think there are any ways of making the Git fetcher faster? | 12:45:15 | |
also these usually use binutils' ld.bfd which sometimes causes weird problems linking C++, so pkgsLLVM.stdenv may be worth a try which uses lld | 12:46:35 | |
* pamplemousse: also these usually use binutils' ld.bfd which sometimes causes weird problems linking C++, so pkgsLLVM.stdenv may be worth a try which uses lld | 12:46:45 | |
| Quick test: fetching github:NixOS/nixpkgs => 16.5s, git+https://github.com/NixOS/nixpkgs => 131.5s, doing the latter again => 11.3s | 12:48:54 | |
| Fetching git+https://github.com/NixOS/nixpkgs?shallow=1 => 85.2s | 12:52:31 | |
| That's probably the best we can do with git. | 12:52:54 | |
| Hmm, thanks | 13:00:40 | |
| The issue is you can't check commit signatures when using the github fetcher | 13:01:01 | |
In reply to @niksnut:matrix.orgI tried this on my own machine, and it did indeed take ages (so long I interrupted it), but time git clone git://github.com/NixOS/nixpkgs --depth 1 took 10.31 seconds according to time. | 13:31:10 | |