Skip to content
This repository has been archived by the owner on Jan 25, 2024. It is now read-only.

on very large files emacs becomes unresponsive #62

Open
NobbZ opened this issue Nov 4, 2021 · 5 comments
Open

on very large files emacs becomes unresponsive #62

NobbZ opened this issue Nov 4, 2021 · 5 comments
Labels
bug Something isn't working
Milestone

Comments

@NobbZ
Copy link

NobbZ commented Nov 4, 2021

Describe the bug

Emacs becomes unresponsive when large files are opened.

Steps to reproduce

Steps to reproduce the behavior:

  1. Open pkgs/top-level/all-packages.nix with the rnix lsp enabled

Expected behavior

Emacs remains responsive

Additional context

  • Version of rnix-lsp: built from master, commit a2d06d2
  • Name and version of the editor you've used: GNU Emacs 29.0.50
  • Operating system: NixOS

Editor configuration is generated by HM, and spread across several modules which generate several emacs packages which are then loaded on start.

The most relevant configuration for rnix-lsp is probably to be found in:

https://github.com/NobbZ/nixos-config/blob/afd01c05fd8cc81b62d55635cd5aa5fbebae0ae0/home/modules/languages/nix/default.nix

@NobbZ NobbZ added the bug Something isn't working label Nov 4, 2021
@aaronjanse
Copy link
Member

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
Copy link
Author

NobbZ commented Nov 5, 2021

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
Copy link

kira-bruneau commented Nov 7, 2021

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
Copy link
Member

Ma27 commented Nov 12, 2021

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).

@Ma27 Ma27 added this to the 0.3.0 milestone Nov 15, 2021
ryantm added a commit to ryantm/dotfiles that referenced this issue Nov 24, 2021
@flurie
Copy link

flurie commented Nov 28, 2021

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.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

5 participants