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