Abysmal performance on basic commands involving nixpkgs

[eclairevoyant]

Commands like

nix build -f https://github.com/NixOS/nixpkgs/archive/refs/heads/master.tar.gz hello

or

nix profile install nixpkgs#hello

gets stuck for tens of minutes (!) after unzipping, sometimes never completing. SIGINT does nothing, have to force stop the app.

[expenses]

The evaluation speed (in a proot at least) is very slow. Once a specific version of nixpkgs has been evaluation cached then things get a lot faster. Running just nixpkgs#<whatever> is generally a bad idea as nixpkgs updates too quickly. Using a specific revision is faster as is just adding/removing packages from a flake.

[eclairevoyant]

taking hours to eval makes this basically unusable 🤷 and why would proot be related? eval happens in-memory. and proot claims to "not cause overhead".

[expenses]

Running nix-on-droid switch takes about a minute for me once evaluation caching is done, which for me is very usable. Perhaps you could try and profile things to see where time is being spent?

[eclairevoyant]

once evaluation caching is done

I feel like this is missing the point - if eval takes over an hour with no guarantee of completion whenever the revision needs updating, I'd have to sit there waiting and hoping it ever completes. There's obviously a design flaw and I'd hope it can be addressed. Or at least, part of the social contract of using open-source software is reporting issues as they are encountered, if no one has done so prior.

[t184256]

OK, my stance on this.

1. IDK who claims "proot doesn't cause overhead", proot tanks IO real hard, and nixpkgs eval is very IO-heavy.
2. proot is the project's chosen way to run unprivileged without recompiling nixpkgs. I have neither the bandwidth to implement our ways of relocating /nix/store, nor the resources to recompile nixpkgs to a new location. Whoever has either of the two, reach out to me and we'll figure something out.
3. Hour-long eval is horrible UX and entirely unreasonable.
4. on a 5 year old Samsung S10e 6GB with LineageOS 19 and wakelock held, nix build -f https://github.com/NixOS/nixpkgs/archive/refs/heads/master.tar.gz hello (i.e., download + unpack + eval) takes less than 8 minutes for me.
5. rm -rf ~/.cache/nix/eval-cache-v5; nix build -f https://github.com/NixOS/nixpkgs/archive/refs/heads/master.tar.gz gnumake immediately after this evaluates in 3.2 seconds
6. time nix profile install nixpkgs#ncdu downloads/unpacks/evals in under 8 minutes.
7. That being said, if you claim that eval takes an hour for you, I'm sorry, but I can neither reproduce that nor advise what should you do about it, besides maybe suggesting you acquire a wakelock and/or follow guidance from https://dontkillmyapp.com

[eclairevoyant]

1. IDK who claims "proot doesn't cause overhead",

Apologies, I misread the comment here: https://wiki.termux.com/wiki/PRoot What it actually said was chroot has no overhead, which makes more sense WRT the performance seen here. If proot fundamentally tanks IO, then fair enough, strace indicates most of the time spent on newfsastat calls.

6. time nix profile install nixpkgs#ncdu downloads/unpacks/evals in under 8 minutes.

8 min is quite reasonable and closer to what I'd expect on a phone. If I can get it there I'd be happy with that.

7. if you claim that eval takes an hour for you, I'm sorry, but I can neither reproduce that nor advise what should you do about it, besides maybe suggesting you acquire a wakelock and/or follow guidance from https://dontkillmyapp.com

Battery saver is off, and "allow background usage" is on. Though, I'd be surprised if doze mode was involved for a foreground app while the screen is on?

Also, I think the link provided is outdated, as I don't see any option for "battery optimization" as mentioned in https://dontkillmyapp.com/google

FWIW I use a Pixel 7 with the current (June) release of android 14.

Other helpful info might be that, the initial bootstrap of nix-on-droid takes about 3 min. I'll run the time command on the fresh install for comparison.

[t184256]

Initial bootstrap definitely involves more than eval'ing a hello, so something is killing the performance afterwards. IDK whether an app can run out of Doze credits while being in foreground, but try (quoting from same device):

• App info - Battery usage - Unrestricted
• Notifications - Nix - Expand - Acquire wakelock