doomemacs / doomemacs

An Emacs framework for the stubborn martian hacker
MIT License
19.32k stars 3.05k forks source link

Doom emacs gets slower over time editing rust files. #5872

Open YellowOnion opened 2 years ago

YellowOnion commented 2 years ago

What did you expect to happen?

Performance is consistent.

What actually happened?

Performance degrades over time, I suspect related to the act of editing the file.

Performance gets better if I leave it for 10 mins idling.

Emacs process is pinned at 100% for a few seconds when it gets really bad, so it's not rls latency or anything like that.

There's a bunch of errors:

https://gist.github.com/YellowOnion/f648cb458ad0127b04e6049631d64456

Describe your attempts to resolve the issue

I tried profiling but not sure how to expand the results in evil mode.

LSP mode is disabled in init.el but it's still running which is probably causing more issues (clashes between racer and rls?)

Steps to reproduce

Edit rust file for 10 mins or so.

System Information

https://gist.github.com/YellowOnion/f648cb458ad0127b04e6049631d64456

YellowOnion commented 2 years ago

Update: I just ran another proflie after it got really laggy:

https://gist.github.com/YellowOnion/a07e1b81fec89bb5d7e910a8756b014c

huwaireb commented 2 years ago

:wave: I'm also getting the same error, with it getting slower over time as well.

Edit: Seems to apply for other languages with lsp such as python with pyright, again downgrading to emacs 28 just fixes it.

I'm running emacs 29.0.5 with pgtk + native comp (Note: downgrading fixes the error).

And flycheck doesn't display diagnostics.

Error running timer ‘lsp--on-idle’: (doom-hook-error lsp-on-idle-hook lsp-diagnostics--flycheck-buffer (error "Two bases given in one event")) Repeats constantly in the messages when flycheck tries to show diagnostics,

M-x toggle-debug-on-error ```Debugger entered--Lisp error: (error "Two bases given in one event") #((keymap (mode-line keymap (mouse-3 . flycheck-next-error) (mouse-1 . flycheck-list-errors))) [mode-line (mouse-4 wheel-up)] #) general-unbind-non-prefix-key(# (keymap (mode-line keymap (mouse-3 . flycheck-next-error) (mouse-1 . flycheck-list-errors))) [mode-line (mouse-4 wheel-up)] #) apply(general-unbind-non-prefix-key # ((keymap (mode-line keymap (mouse-3 . flycheck-next-error) (mouse-1 . flycheck-list-errors))) [mode-line (mouse-4 wheel-up)] #)) define-key((keymap (mode-line keymap (mouse-3 . flycheck-next-error) (mouse-1 . flycheck-list-errors))) [mode-line (mouse-4 wheel-up)] #) doom-modeline-update-flycheck-text(errored) flycheck-report-status(errored) flycheck-report-failed-syntax-check() flycheck-buffer() flycheck-buffer-automatically(save) flycheck-handle-save() funcall(flycheck-handle-save) (condition-case e (funcall hook) ((debug error) (signal 'doom-hook-error (list hook e)))) doom-run-hook(flycheck-handle-save) run-hook-wrapped(doom-run-hook flycheck-handle-save) (condition-case e (run-hook-wrapped hook #'doom-run-hook) ((debug doom-hook-error) (if debug-on-error nil (lwarn hook :error "Error running hook %S because: %s" (if (symbolp (car (cdr e))) (symbol-name (car (cdr e))) (car (cdr e))) (car (cdr (cdr e))))) (signal 'doom-hook-error (cons hook (cdr e))))) (let ((hook (car --dolist-tail--))) (condition-case e (run-hook-wrapped hook #'doom-run-hook) ((debug doom-hook-error) (if debug-on-error nil (lwarn hook :error "Error running hook %S because: %s" (if (symbolp (car ...)) (symbol-name (car ...)) (car (cdr e))) (car (cdr (cdr e))))) (signal 'doom-hook-error (cons hook (cdr e))))) (setq --dolist-tail-- (cdr --dolist-tail--))) (while --dolist-tail-- (let ((hook (car --dolist-tail--))) (condition-case e (run-hook-wrapped hook #'doom-run-hook) ((debug doom-hook-error) (if debug-on-error nil (lwarn hook :error "Error running hook %S because: %s" (if (symbolp ...) (symbol-name ...) (car ...)) (car (cdr ...)))) (signal 'doom-hook-error (cons hook (cdr e))))) (setq --dolist-tail-- (cdr --dolist-tail--)))) (let ((--dolist-tail-- hooks)) (while --dolist-tail-- (let ((hook (car --dolist-tail--))) (condition-case e (run-hook-wrapped hook #'doom-run-hook) ((debug doom-hook-error) (if debug-on-error nil (lwarn hook :error "Error running hook %S because: %s" (if ... ... ...) (car ...))) (signal 'doom-hook-error (cons hook (cdr e))))) (setq --dolist-tail-- (cdr --dolist-tail--))))) doom-run-hooks(after-save-hook) apply(doom-run-hooks after-save-hook) run-hooks(after-save-hook) basic-save-buffer(nil) save-buffer() evil-write(nil nil nil nil nil) funcall-interactively(evil-write nil nil nil nil nil) call-interactively(evil-write) evil-ex-call-command(nil #("w" 0 1 (ex-index 1)) nil) eval((evil-ex-call-command nil #("w" 0 1 (ex-index 1)) nil)) evil-ex-execute(#("w" 0 1 (ex-index 1))) evil-ex(nil) funcall-interactively(evil-ex nil) command-execute(evil-ex)```
ulysses4ever commented 2 years ago

Have the same problem with Haskell LSP. NixOS, Emacs 29 pgtk+native comp. Plenty of "Two bases given in one event".

YellowOnion commented 2 years ago

I moved to gccEmacs i.e. v28 and still getting issues with c coding now.

I'm extremely close to giving up on emacs, I feel like i'm wrangling with layers and layers of crap, and projects like spacemacs and doom macs are trying to fix issues but they also hide issues and make it so hard to debug, you find a guide on profiling emacs, but they specify all the controls in normal vanila emacs, and even doom emacs seems to tell you on occasion to use ctrl+X instead of the evil equivalent.

With that being said I've FINALLY figured out how to interact with the profiler:

And guess what is causing the issues! evil mode.

image

anonimitoraf commented 2 years ago

Wow, any theories why?

azzamsa commented 2 years ago

Same here. I need to restart Emacs each time this issues arises.

❯ .emacs.d/bin/doom version
> Executing 'doom version' with Emacs 29.0.50 at 2022-01-30 13:30:56
  GNU Emacs     v29.0.50         2ab73286b7a58eb983da21bca8b781ec884eb996
  Doom core     v3.0.0-alpha     HEAD -> master 9cfd7980 2022-01-30 02:42:54 +0100
  Doom modules  v21.12.0-alpha   HEAD -> master 9cfd7980 2022-01-30 02:42:54 +0100

~
❯ sfetch
OS: Debian GNU/Linux 11 (bullseye)
Kernel: Linux 5.10.0-10-amd64
CPU: Intel(R) Core(TM) i5-7200U CPU @ 2.50GHz
Memory: 3923516 kB
Emacs version: GNU Emacs 29.0.50 (build 4, x86_64-pc-linux-gnu, GTK+ Version 3.24.24, cairo version 1.16.0) of 2022-01-06

~
❯ rust-analyzer --version
rust-analyzer 183ef048f 2021-11-22 stable
brotzeit commented 2 years ago

I know it's tempting to use an unstable emacs version to get the latest performance improvements, but you should just switch to a stable version after you reported an annoying bug like this https://www.gnu.org/software/emacs/history.html. I also know many of you use arch(so do I) but in terms of emacs it's not the best solution to use a rolling release distro, unless you want to find and fix bugs.

bleggett commented 10 months ago

I still see this quite a bit with stable 29.1.

It is reliably triggered (or at least exacerbated) for me if I split the buffer on the same file, and have two different views of the same file at once.

Closing one of the views does not fix the issue, only an emacs restart does.

Weirdly, opening rustic-popup seems to speed it back up again.

It's not related to lsp, as I see the same problem if I disable that - seems to be rustic itself.