GNU bug report logs - #43389
28.0.50; Emacs memory leaks

Previous Next

Full log

View this message in rfc822 format

From: "Jose A. Ortega Ruiz" <jao <at> gnu.org>
To: "Lars Ingebrigtsen" <larsi <at> gnus.org>
Cc: 43389 <at> debbugs.gnu.org
Subject: bug#43389: 28.0.50; Emacs memory leaks
Date: Wed, 09 Dec 2020 21:04:58 +0000

On Wed, Dec 09 2020, Lars Ingebrigtsen wrote:
[...]

> Has anybody tried compiling a list of features people who see the leaks
> are using?  Not that there's really any good way of gathering that data,
> but ...  Like, helm is known for using lots of memory, and eww can, too,
> under some circumstances, and so can image caching...

in my case, it's ivy and emacs-w3m.  the first burst i observe is
usually at the beginning, so not many of the miriad other packages i use
have been active at all.  i use exwm, so that's one that's always there
for sure, and ivy takes control immediately, but little else seems
"needed".

regarding images, i use pdf-tools, and it has a heavy memory footprint
(opening any PDF increases easily emacs ram consumption in 200Mb, no
matter how big the PDF). but those jumps are immediate upon opening the
doc.

in my case, another source of puzzlement is this "bursty" behaviour.
after the firs one, i can be at ~1Gb for a day or two (doing almost
everything inside emacs, so all kinds of packages used), and then,
without any change in my usage patterns i could tell, a new burst will
take my RAM, 10Mbs at a time, up to ~2Gb.  and then stop, again without
me doing, concisouly, anything differently.

jao
-- 
To see ourselves as others see us is a most salutary gift. Hardly less
important is the capacity to see others as they see themselves.
 -Aldous Huxley, novelist (1894-1963)

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.