I'd doubt it's treesitter. It could be, of course. The LSP server more likely. If using Linux run htop or something and check memory usage. Edit: Mac. Find the htop equivalent.
this post was submitted on 26 Nov 2023
1 points (100.0% liked)
Emacs
310 readers
2 users here now
A community for the timeless and infinitely powerful editor. Want to see what Emacs is capable of?!
Get Emacs
Rules
- Posts should be emacs related
- Be kind please
- Yes, we already know: Google results for "emacs" and "vi" link to each other. We good.
Emacs Resources
Emacs Tutorials
- Beginner’s Guide to Emacs
- Absolute Beginner's Guide to Emacs
- How to Learn Emacs: A Hand-drawn One-pager for Beginners
Useful Emacs configuration files and distributions
Quick pain-saver tip
founded 1 year ago
MODERATORS
Thank you for the hint. It is even prior to the LSP (I think), because I run the LSP within a virtualenv that I can choose to not activate. And in either case it is Emacs taking up like 30+ GB of memory until I force kill it: https://imgur.com/a/F6liREU
Well, they used to call it "Eight Megabytes and Constantly Swapping" :-) One could only wish, now!
Seriously, I've also seen some poor behavior with ts-mode and ts-folding also, maybe with python or yaml, ending in a hang or crash, not sure of specifics yet. I'll pay better attention next time.
Several comments:
- based on the CPU utilization, I'm guessing there's an error condition that causes a spin that continually tries to allocate memory.
- in my experience, things like this are often visible if you trace the executable. Unfortunately, OSX makes this unpleasant: https://www.shogan.co.uk/devops/dtrace-dtruss-an-alternative-to-strace-on-macos/.
- if you send a
kill -11
to the process, you should get a corefile of the running process. Running something likestrings
orhexdump
against the resulting image (you'll want to remove it when you're complete) might make the problem obvious. There should be a way to start the process with limited memory to avoid generating a 30GB core file.