rustic
rustic copied to clipboard
brotzeit
Occasionally emacs gets slow and freezes
Somebody opened an issue about rustic being slow and sometimes freezes reddit
I could reproduce this myself with master AND 1.4(that was before we added the dependency on rust-mode).
It's also possible that it's related to another package(e.g. company). At this moment I can only say that lsp is not the reason.
If anybody else encounters this issue please give some info like which packages you are using with rustic. I recently switched devices and I didn't notice this bug before. Maybe I haven't updated my packages for a while...
How did you reproduce it? I haven't coded in Rust for over a year, but just opening a large project and navigating around it works fine.
I started typing "let foo = a." and then it happened. That's why I think it could be related to auto completion. But I also know that rust-mode runs lots of functions for mode related features. One thing I also noticed is that my cpu was at 100% usage until I killed emacs.
Still can't reproduce, I'm actually surprised at how snappy everything feels.
Again. So there's definitely a bug(now it occurred while typing in parentheses).
It seems to go slow for me sometimes when typing brackets. I think its related to lsp however and not rustic, hitting M-x or jumping to the top or bottom of the file seems to fix it.
It seems to go slow for me sometimes when typing brackets. I think its related to lsp
It could also be a package like smartparens. It appears to me like a regex isn't working as it should.
hello i am sorry about reddit post and for delay to reply and thanks for your response
https://user-images.githubusercontent.com/56762707/141684019-6c06ea4d-1bf1-4e06-84e6-7bc0c4a82ed5.mp4
i use emacs 29 may be the problem
Could you try it with a stable version of emacs?
@samhedin the problem seems with emacs 29.0.50.151452 i will try the last ver of emacs
emacs-29 (gcc-wayland-bin) user here. This is quite problematic, could be related to rustic-mode not correctly spawning rust-analyzer (it somehow doesn't use workspaces and if you have a multi-workspace project it fails to work properly.
I encountered this bug without lsp. I'll try to switch to emacs29 again and see if I can figure it out.
@appetrosyan could you try doom emacs i think the problem with cargo.el not with rustic
edit the problem seems not in rustic mode or cargo.el
I am getting very poor performance. All the time seems to be lsp-ui-doc--make-request and then symbol-at-point. Will poke further, but interested to know if anyone is getting this.
~I wonder if this can't be connected to this strange issue with evil-mode https://github.com/emacs-evil/evil/issues/1559~
ruled that out - it's not related
You should use emacs28 for now. I didn't encounter this issue since I stopped using emacs master.
Not sure if it's same issue but posting in case.
Windows 10 emacs-27.2-x86_64-installer rustc 1.59.0 rust-analyzer 2022-03-14 stable
When using rustic-mode with lsp-mode, my emacs freezes whenever I save an .rs file. Using same config with rust-mode + lsp-mode solves the problem.
@waylandc nobody mentioned windows issues so far, but I already thought that some stuff won't work. I doubt this is related so I open a new issue.
I actually figured what was the issue in my case. It was not related to rustic. There seems to be bug with system clipboard handling. The issue I was experiencing was happening when content of my clipboard contained some data that emacs didn't like so functions that worked with clipboard in one way or another got stuck. For me this was caused by aseprite. The workaround is to copy some plaintext to clipboard with which emacs can deal with.
Update. The freezes seem to become less frequent and disappear entirely if I disable LSP. I suspect that the GC might be the culprit. A fix could be increasing (or reducing) the GC threshold. Will update after more testing.
I found a workaround, that significantly changed the odds of freezing.
TL; DR
( setq gcmh-idle-delay 1)
I use a package called gcmh (GC magic hack), which dynamically adjusts the gc-cons-threshold based on activity. It is supposed to help with LSP-based memory allocations, but it turned out to do the exact opposite. The reason was that by default, the idle delay is set to 15 seconds. I reduced it down to 1.
How it works.
When you type and do stuff there's usually <1 second between actions. There are some infrequent pauses, which take something like 1-2 seconds, maybe more, and then you start typing again.
Before, if you had a few pauses 7 seconds each, and then a large pause of 16 seconds. With the old settings, you'd gather all the garbage that accumulated over those previous sessions at the end of the 15 second pause. It takes a few seconds, so the freeze is noticeable. With the new setting, you're cleaning up more often. Each little stop triggers GC and you have more frequent shorter pauses, rather than one large contiguous pause.
I think that this info should be on the front page of the project.
I would put it at the top of the readme under "known issues". But this should also be mentioned at lsp-mode if it helps. Maybe we should discuss it over there.
I think this can be symptom of different issues. For me (NOT rigorously tested) I recall the freezes happened when I try to use rustic code block in org mode to execute erroneous code. Emacs will not respond to keystrokes (read: NOT frozen! It still respond to resizing to repaint my terminal), stuck at "Executing" state for around 1 to 5 minutes until the compilation error got printed out.
Sometimes I wait for it, in which it eventually become responsives again.
Sometimes I use ps to kill the cargo process and send a USR2 signal via kill then Emacs may goes back to a usable state, or crashes fatally.
If anyone think mine is a different issue I move this to a new one.
