nix icon indicating copy to clipboard operation
nix copied to clipboard

Poor performance of `nix build --debugger`

Open kjeremy opened this issue 1 year ago • 3 comments

Describe the bug

Adding --debugger to an invocation of nix build adds many minutes to a build. From the order of 30 seconds without the option to over 20 minutes on one of my flakes.

Steps To Reproduce

nix build .#blah --debugger

Expected behavior

I would expect that performance would be similar to a build without --debugger.

nix-env (Nix) 2.22.1

Additional context

Add any other context about the problem here.

Priorities

Add :+1: to issues you find important.

kjeremy avatar May 28 '24 14:05 kjeremy

Triaged in Nix maintainers meeting:

  • @roberth this concerns only the evaluator and maintains some extra data, the slowdown should not be more than 2x

@kjeremy could you please provide more detailed reproduction steps, it may pertain to your code.

fricklerhandwerk avatar May 29 '24 19:05 fricklerhandwerk

This issue has been mentioned on NixOS Discourse. There might be relevant details there:

https://discourse.nixos.org/t/2024-05-29-nix-team-meeting-minutes-148/46195/1

nixos-discourse avatar May 29 '24 21:05 nixos-discourse

@fricklerhandwerk That wouldn't surprise me. We have a flake that builds 60ish proprietary native packages and about 20+ cross-compiled nixos systems. I can't distribute any of it but I'll try to come up with some kind of representative example.

kjeremy avatar May 30 '24 14:05 kjeremy

time nix run .#rosPackages.noetic.mrak_test_results_coverage --debug

gives

real 0m13.060s user 0m5.782s sys 0m1.896s

With --debugger

I'm running with --debugger --debug and noticing that the same things are being instantiated multiple times including the following two that I happened to Ctrl+C out of.

performing daemon worker op: 7
instantiated 'glibc-2.39.tar.xz' -> '/nix/store/gxv8zyycd4g400h51gfzpg0isk3b7qqd-glibc-2.39.tar.xz.drv'
performing daemon worker op: 7
instantiated 'glibc-2.39-52' -> '/nix/store/1whh7vxmcz14dym0h9453hpiqcw7lkcf-glibc-2.39-52.drv'

error: interrupted by the user

real	4m29.427s
user	3m42.872s
sys	0m21.521s

kjeremy avatar Jul 23 '24 14:07 kjeremy

Yup super poor performance.

mightyiam avatar Oct 07 '24 06:10 mightyiam

I'm getting hit by this as a result of the 24.11 nixpkgs release.

Nix 2.18 builds my systems in ~30 seconds. I gave up waiting after 20 minutes with Nix 2.24. Removing "--debugger" arg avoids the performance regression.

ccdunder avatar Nov 23 '24 10:11 ccdunder

This regression makes the latest Nix pretty much unusable for me. I just tested a bunch of different nix versions and found that this was regressed in nix 2.21.


Edit: Actually it could also be in 2.22. I can't meaningfully test 2.21 because it's seemingly trying to copy my entire root to the /nix/store.

$ nix run nixpkgs#nixVersions.nix_2_21 -- eval nixpkgs#hello.outPath --no-eval-cache -vv
evaluating file '<nix/derivation-internal.nix>'
copying '/nix/store/4r8s42c9mwfvgdlxv0izb1cmlzrsb5nz-source'...
copying '/' to the store

Basically to reproduce (make sure to warm up):

# Normal
$ nix run nixpkgs#nixVersions.nix_2_20 -- eval nixpkgs#hello.outPath --no-eval-cache -vv --debugger --ignore-try

# Extremely slow
$ nix run nixpkgs#nixVersions.nix_2_22 -- eval nixpkgs#hello.outPath --no-eval-cache -vv --debugger --ignore-try

szlend avatar Nov 23 '24 11:11 szlend

Thanks for providing a simple repro @szlend! I ran a bisect locally and narrowed it down to 5d9fdab3d.

Runtime of eval nixpkgs#hello.outPath --no-eval-cache -vv --ignore-try with --debugger vs. without: 5d9fdab3d: 73.38 sec / 0.82 sec 855fd5a1b (parent): 1.62 sec / 0.83 sec

ccdunder avatar Nov 24 '24 09:11 ccdunder

As to the root cause, perhaps @pennae has insight?

My completely un-expert guess is that the cost added in that commit to calculate exact position info is being incurred when running with --debugger.

ccdunder avatar Nov 24 '24 09:11 ccdunder

this concerns only the evaluator and maintains some extra data, the slowdown should not be more than 2x

The slowdown is more like 45x. Imo this should be labeled as a regression since it worked fine in 2.18 (regressed in 2.21). Right now --debugger is unusable in practice.

simonzkl avatar Jan 12 '25 11:01 simonzkl