Measuring the overhead of nixpkgs

Today I spent some time benchmarking how long it takes to build derivations.

https://zimbatm.com/benchmark-nixpkgs/

3 Likes

Out of curiosity: did you also try to build with sandboxing disabled to see what the overhead of setting up the sandbox is?

I was too lazy to re-configure my system :slight_smile: I know that the overhead is quite significant based on a previous discussions: Chroot builds are slow · Issue #179 · NixOS/nix · GitHub

If you want to play with the code, another thing you can try out is with or without the daemon to see if there is any overhead there. But both of these things are testing more the baseline than the nixpkgs overhead which was the goal of this small project.

It’s a little bit of apples to oranges comparison. mkDerivation does have some overhead, but it also provides stdenv common-path.nix and other tools. I suspect the main difference comes from it having to evaluate those extra drvs. mkDerivation definitely has room to improve its cost, but 2-3x overhead is probably unavoidable.

I don’t know. There has been a lot of times in my career where I was sure and then I measured and it was something completely different. The nixpkgs code hasn’t really been traced to understand where the time is being spent. Maybe there are some functions that are very expensive. Or some code that is evaluated many times and can be hoisted.

The Nix interpreter hasn’t really been optimized either, I wouldn’t be surprised if there were a few low-hanging fruits there.

Another idea would be to rewrite pkgs.runCommandNoCC based on the builtin derivation. That would speed up a subset of nixpkgs at least.