search

nix-community / neovim-nightly-overlay

[maintainer=@GaetanLepage, @willruggiano]
https://matrix.to/#/#neovim-nightly-overlay:nixos.org
287 stars 39 forks source link

Constant full CPU core load on x86-64 darwin #538

Closed konradmalik closed 3 weeks ago

konradmalik commented 3 weeks ago

Hey, after updating this repo to this commit (and later): https://github.com/nix-community/neovim-nightly-overlay/commit/bd7497d3a7eadddebd9f547e4aab7ea204c892a3 neovim on x86_64-darwin for some reason consumes one full CPU core constantly. Tried with both, current state of this flake, and overriding inputs to the newest neovim-src and nixpkgs.

Facts I know:

Can it be something with tree-sitter?

Filing the issue here but I'm not sure if the issue is here or in nixpkgs. Happy to provide more info and help in any way.

image
willruggiano commented 3 weeks ago

So, immediately upon opening neovim your cpu's pegged? Are there any clues in :checkhealth? What about Activity Monitor, any clues in there or does it just claim "neovim" is the culprit?

konradmalik commented 3 weeks ago

Not immediately after opening. Only after opening any file, or after opening file preview via telescope. That's why the first thing that came to my mind was treesitter but not sure how to check that.

Activity monitor just shows "nvim - 99.9" in the cpu column and laptop gets hot.

Checkhealth shows nothing suspicious but I'll post both reports later (compiled and binary from neovim repo), maybe it'll show some differences, because one works ok, the other not.

willruggiano commented 3 weeks ago

I see. Unfortunately I do not have a macOS to try and repro on my own.

From what you've described, I am suspicious of the dependencies for which we are overriding derivation inputs. If you have time and are so inclined, could you try commenting out the overridden dependencies here (around L50); https://github.com/nix-community/neovim-nightly-overlay/blob/master/flake/packages/neovim.nix

Let me know if you need help forking/cloning this repo and/or getting your neovim flake to point at your local copy.

konradmalik commented 3 weeks ago

Thanks for a good lead! After trial and error, the cause seems to be: libuv (after commenting it out in overrides, nvim compiled from this repo behaves normally). Here's a workaround that fixes the issue in my flake: https://github.com/konradmalik/neovim-flake/commit/3d71a41a990c279204ba8dfe5c7b6749edc3d7ba

But I'm not sure how we should proceed in this repo to fix it. Any suggestions? What's weird is that both nixpkgs and neovim deps.txt file seem to have the same libuv version (1.48), but they still behave differently on darwin.

willruggiano commented 3 weeks ago

Interesting! Although not totally surprising. You said the binary release (or build) for the same upstream commit does not exhibit this cpu problem? I guess we need to go dig through neovim's cmake code :D

Anyways, thanks for filing this issue! I can take it from here. Will commit a temporary fix until I have time to investigate what could be the real root cause here.

konradmalik commented 3 weeks ago

Hmm, so this works properly (current nixpkgs):

            libuv = pkgs.libuv.overrideAttrs {
              src = pkgs.fetchFromGitHub {
                owner = "libuv";
                repo = "libuv";
                rev = "v1.48.0";
                hash = "sha256-U68BmIQNpmIy3prS7LkYl+wvDJQNikoeFiKh50yQFoA=";
              };
            };

While this does not (neovim's deps.txt):

            libuv = pkgs.libuv.overrideAttrs {
              src = pkgs.fetchurl {
                url = "https://github.com/libuv/libuv/archive/v1.48.0.tar.gz";
                sha256 = "8c253adb0f800926a6cbd1c6576abae0bc8eb86a4f891049b72f9e5b7dc58f33";
              };
            };

I know the above is the same what we concluded earlier, but seems more clear to show this explicitly.

Does it mean that v1.48.0 used in nixpkgs (downloaded from source directly) is not the same as v1.48.0 locked in neovim's repo (downloaded from the released tarball)? Edit1: nope, downloaded both, diffed, and they're the same except for the .git folder.

And then, I still cannot understand why a pre-built binary from neovim works fine...

Edit2: the below also works (!); seems like something's fishy in fetchurl on darwin?

            libuv = pkgs.libuv.overrideAttrs {
              src = pkgs.fetchzip {
                url = "https://github.com/libuv/libuv/archive/v1.48.0.tar.gz";
                hash = "sha256-U68BmIQNpmIy3prS7LkYl+wvDJQNikoeFiKh50yQFoA=";
              };
            };

Edit3: I've built libuv using both fetchzip and fetchurl, then used nix-diff to compare both packages. Attaching nix-diff.txt (it's quite long). I've never used that tool and not sure how to interpret the results and how good they're, but at first sight looks like a lot of differences that I didn't expect (even 24.11 vs 24.05).

Edit4: included fetchTarball into the equation:

For the interested a branch where there's 3 libuvs defined for easy testing: https://github.com/konradmalik/neovim-flake/tree/darwin-fix

If this matters, my nix version: 2.22.1

Edit5: comparing files produced by two derivations as follows shows no differences, but still libuv built with fetchurl vs fetchzip behaves differently 

        libuv-fetchurl = pkgs.stdenv.mkDerivation {
          name = "libuv-fetchurl";
          src = builtins.fetchurl {
            url = "https://github.com/libuv/libuv/archive/v1.48.0.tar.gz";
            sha256 = "8c253adb0f800926a6cbd1c6576abae0bc8eb86a4f891049b72f9e5b7dc58f33";
          };
          installPhase = ''
            cp -r ./ $out/
          '';
        };
        libuv-fetchzip = pkgs.stdenv.mkDerivation {
          name = "libuv-fetchzip";
          src = pkgs.fetchzip {
            url = "https://github.com/libuv/libuv/archive/v1.48.0.tar.gz";
            hash = "sha256-U68BmIQNpmIy3prS7LkYl+wvDJQNikoeFiKh50yQFoA=";
          };
          installPhase = ''
            cp -r ./ $out/
          '';
        };