bug#38345: 27.0.50; Permanent increase in memory consumption after opening images (or pdfs)

[Eli Zaretskii]

> From: Ihor Radchenko <yantar92@gmail.com>
> Cc: juri@linkov.net, 38345@debbugs.gnu.org
> Date: Mon, 02 Dec 2019 16:04:46 +0800
> 
> > The doc string assumes "normal" operation, it doesn't assume some Lisp
> > command runs for a long time, thus preventing redisplay.
> 
> Sounds counter-intuitive. Elisp commands can run for a long time
> (pointing at org-agenda). 

Commands that run for a long time make Emacs unresponsive, and
therefore are a misfeature or a bug.

That said, a command that runs a long time is unlikely to create many
images, destroying each one before creating the next one, because
what would be the point of that?

IOW, yours is a scenario that is infrequent at best, IMO.

> I tried to look at the code, but I have to admit that I don't understand
> the reason. Probably because of my poor C. 

Feel free to ask questions about the details you don't understand.

> In any case, I tried different approach trying to reduce memory
> fragmentation. Instead of using the default malloc/free, I used jemalloc
> through LD_PRELOAD. For periodic cache clearing (every 2,10,50, and 100
> opened/killed images), there was no noticeable difference in the memory
> consumption. However, when I tried to open a bunch of images all
> together, killed them, and cleared the cache (as in my initial bug
> report), the jemalloc instance of emacs showed much lower memory
> consumption (~240Mb vs 1200Mb). 

I don't think replacing the system malloc on GNU/Linux systems (let
alone on others) is an idea we'd like to pursue.  You may have more
luck playing with mallopt calls in init_alloc_once_for_pdumper
(assuming your build defines DOUG_LEA_MALLOC).