on very large files emacs becomes unresponsive about rnix-lsp

[aaronjanse]

Thank you for the Nix expression! :-)

That'll make things much easier to reproduce, since this seems to be working for me without an issue in my dev environment

[NobbZ]

I just checked HTOP, and it seems as if just emacs is going to hog a single CPU, the LSP though doesn't appear to consume any mentionable resources… Its there at 0.1% CPU and ~20k of RES memory.

Though if I manage to kill the LSP using M-x lsp-workspace-shutdown RET emacs becomes responsive again and I can browse the file and operate emacs normally.

If I temporarily blacklist my local nixpkgs clone and open the mentioned file again, there are also no issues, as soon as I start the LSP manually, emacs is unresponsive again.

Perhaps something in lsp-mode that might cause this behaviour due to too large responses?

[kira-bruneau]

I've definitely noticed a slowdown (especially on pkgs/top-level/all-packages.nix) since the change that adds links on paths. I'm not sure if that's related?

[Ma27]

Not an emacs expert, but it seems as if the issue can be mitigated by declaring e.g. (setq lsp-idle-delay 0.500) (see https://emacs-lsp.github.io/lsp-mode/page/performance/). Would you mind checking if that's the case?

As a next step I'd try to narrow down what the actual problem is (though the link-path thing is rather likely then) and evaluate possible solution (such as only evaluating a subset of all link-paths).

[flurie]

I've been having this issue on macOS as well. I've taken to editing all-packages.nix in vim as a stopgap.

Setting lsp-idle-delay to 0.5 does not seem to mitigate the issue enough to make it usable with all-packages.nix.