bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#56546: 29.0.50; unbounded RAM comsumption when displaying images


From: Eli Zaretskii
Subject: bug#56546: 29.0.50; unbounded RAM comsumption when displaying images
Date: Thu, 14 Jul 2022 09:04:51 +0300

> Cc: 56546@debbugs.gnu.org
> Date: Thu, 14 Jul 2022 08:45:24 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> 
> > From: "Jose A. Ortega Ruiz" <mail@jao.io>
> > Date: Thu, 14 Jul 2022 02:35:46 +0100
> > 
> > 
> > It seems to be easy to make emacs (under X) to consume more and more
> > RAM, which is never released, by making it display images.  A extreme
> > (in my experience) case is animated GIFs, try:
> > 
> >   - emacs -Q
> >   - M-x eww RET https://xenodium.com/emacs-zones-to-lift-you-up/
> >   - RAM consumption grows to ~600Mb
> >   - R (redisplay page): RAM grows to ~1100Mb
> >   - R (redisplay page): RAM grows to ~1752Mb
> >   - R (redisplay page): RAM grows to ~2222Mb
> >   - rinse and repeat: RAM never goes down
> >   - (image-cache-size) reports a modest 82Mb
> >   - Kill buffer:  high RAM consumption is still at its maximum, even
> >     after (image-cache-size) goes to 0
> 
> Run some utility that displays the memory-map of an application, and
> you will see that most of that memory is free for use.  Emacs just
> didn't release it to the OS, but kept it in the memory pages allocated
> to the process, for future allocations.
> 
> The strategy for releasing memory to the OS is in glibc, not under our
> control.  Last time we talked with glibc developers, they maintained
> that this is the expected and correct behavior.

Btw, did you try

  M-: (clear-image-cache) RET

followed by "M-x garbage-collect RET"?





reply via email to

[Prev in Thread] Current Thread [Next in Thread]