hyprland takes more than 6GiB RAM to build

[sumit-modak]

After the hyprland update v0.50.1 came out I am trying to rebuild by system in nixos, and I couldn't able to do so since then.
I have 7.11 GiB of RAM (no swap) on my laptop. Each time I tried to rebuild my laptop freezes. Is there any way to fix this?

[rszyma]

Have you checked in process monitor that it's actually hyprland compilation that causes OOM? It doesn't sound like hyprland issue, it's probably nix issue.

Here's couple of thing you can try, of top of my head:

1. Switch to nix 2.30, which landed a couple days ago. It has some significant memory usage improvements (should use -20% less memory) over previous version.
2. If you're using flakes you want use follows in input whenever possible, this decreases both memory use and cpu time for eval. Don't use follows for hyprland flake tho (it might cause build failure).
3. If you're using flake from hyprland repo it will most likely cause build locally, which is resource hungry. You could try using hyprland from nixpkgs repo, because there are prebuild binaries available for it from cache.nixos.org

[sumit-modak]

I dont have the hyprland url in my flake inputs. I have

  programs.hyprland = {
    enable = true;
    xwayland.enable = false;
    withUWSM = true;
  };

this in my config. As you mentioned using hyprland from cache.nixos.org, how to do that?

And this is the system monitor while nix is building hyprland

I took this just before my laptop freezed

[ryincler]

Builds for Hyprland with programs.hyprland.xwayland.enable = false; aren't built to be cached on cache.nixos.org. If you don't want to compile, set it to true and then you can use the cached derivation again.

As for OOM while compiling, maybe get some swap.

[sumit-modak]

Yeah, it worked! But why is that?

[ryincler]

Because if you look in the module definition in nixpkgs, that option passes in a different argument to the hyprland package. That leads to the hash changing, and since Hydra didn't build this for the cache, you now have to compile it.

[vaxerski]

We don't really scrutinize RAM usage when compiling...