!VRULIdgoKmKPzJZzjj:nixos.org

Nix Package Manager development

870 Members
For people hacking on Nix: https://github.com/NixOS/nix Nix maintainers can be reached here.182 Servers

You have reached the beginning of time (for this room).


SenderMessageTime
21 Oct 2025
@xokdvium:matrix.orgSergei Zimmerman (xokdvium)I think I understand what’s going on. Will poke around soonish and see15:13:25
@juliankuners:matrix.orgJulian Yea, me somwhat too. It is actually the checkout issue, but it's caused by a checkout of the mis-cached repository in another CI on the same CI machine, see here. The timestamp of the CI job and the cache entry in the sqlite database match exactly, same as the wrong nix store path 72alw9m62226brv4v4m98fqrk31mlp34. 15:21:07
@juliankuners:matrix.orgJulianI created a respective issue, highlighting the I suppose actual root cause, all things considered https://github.com/NixOS/nix/issues/1431717:03:51
@dramforever:matrix.orgdramforever
In reply to @juliankuners:matrix.org
I created a respective issue, highlighting the I suppose actual root cause, all things considered https://github.com/NixOS/nix/issues/14317
oh yeah that's a duplicate of https://github.com/NixOS/nix/issues/13698
17:13:40
@dramforever:matrix.orgdramforeverguess i was a few hours late to the discussion17:15:47
@juliankuners:matrix.orgJulianThank you, I missed this one during my issue search. I closed it and linked to it in the respective other issue.17:19:57
@echobc:matrix.org@echobc:matrix.org joined the room.18:09:44
@mjolnir:nixos.orgNixOS Moderation Bot banned @echobc:matrix.org@echobc:matrix.org (<no reason supplied>).18:09:44
@niksnut:matrix.orgEelco learned today that using std::string for large buffers is very inefficient (huge kernel overhead): https://github.com/DeterminateSystems/nix-src/pull/238/commits/edf45d6e1158a059e7ded5460d2a3947dc35fdf8 20:44:48
@xokdvium:matrix.orgSergei Zimmerman (xokdvium)This is sort of more about doing unnecessary construction/destruction of an object. Not special to std::string in any way20:55:40
@niksnut:matrix.orgEelcoit's a result of having a large contiguous allocation (so it would also affect std::vector<char>)20:56:21
@xokdvium:matrix.orgSergei Zimmerman (xokdvium)Yeah, it's much better to allocate once and reuse that allocation as you did there20:56:45
@niksnut:matrix.orgEelcoa data type that consists of a vector of buffers would avoid this problem20:57:06
@xokdvium:matrix.orgSergei Zimmerman (xokdvium)I did a similar cleanup in filetransfer..cc at some point20:57:07
@xokdvium:matrix.orgSergei Zimmerman (xokdvium)You'd still benefit from allocating it only once though20:57:23
@xokdvium:matrix.orgSergei Zimmerman (xokdvium)Going through malloc/free is still a function call through PLT and doing that in a loop is kind of expensive anyway20:58:05
@xokdvium:matrix.orgSergei Zimmerman (xokdvium)https://llvm.org/docs/ProgrammersManual.html#vector20:58:58
@niksnut:matrix.orgEelcoit's funny though that the optimization that skipped parsing 15 GB of NARs (https://github.com/DeterminateSystems/nix-src/pull/238/commits/1f8d587a0df8f9de366640831dade43d17021c30) had basically no observable effect21:01:55

Show newer messages


Back to Room ListRoom Version: 6