Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

I'm assuming the opposite - they're running on a machine with lots of memory, and Emacs is getting bogged down by frequent and slow GC pauses. I have run into this problem myself and actually quit using Emacs because its GC lag was so bad.


yeah, this is correct. iirc it was some sort of "autocomplete open a file" library that was running slowly, mostly because of gc -- disabling gc made that snappy, and i have enough memory that it doesn't really matter if emacs never reclaims it.

i also really don't like having my editor pause to do gc.

(i'm addicted to emacs flexibility, but i would love a better-engineered replacement. maybe xi editor, someday. (though their multiprocess approach seems _insane_ to me, _especially_ in a language that gives you safe shared-memory concurrency!))

here's the necessary incantations, in any case anyone wants to try this at home:

  ;; never collect.
  (setq gc-cons-threshold 10000000000)
  (defun garbage-collect (&rest args) 
	  (message "trying to garbage collect. probably you want to quit emacs."))
  (setq garbage-collection-messages t)
the message kicks in at 10GB.


Could turning it off cause other issues (in Emacs / in OS), apart from eating lots of memory?


The OOM killer preferentially targets processes with a lot of memory allocated. If you actually let emacs consume all memory it's likely to die without warning.


so far so good, been doing it since january (so coming up on 1 year).

i remembered what the driving reason was to disable gc:

turning off gc gets my emacs startup time down to ~400ms from ~600ms.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: