From: "Jose A. Ortega Ruiz" <mail@jao.io>
To: Eli Zaretskii <eliz@gnu.org>
Cc: 56546@debbugs.gnu.org
Subject: bug#56546: 29.0.50; unbounded RAM comsumption when displaying images
Date: Thu, 14 Jul 2022 13:23:01 +0100 [thread overview]
Message-ID: <87h73j3mu2.fsf@mail.jao.io> (raw)
In-Reply-To: <8335f4uu17.fsf@gnu.org> (Eli Zaretskii's message of "Thu, 14 Jul 2022 08:45:24 +0300")
On Thu, Jul 14 2022, Eli Zaretskii wrote:
>> 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.
then, why is the process not reusing that memory the second, third,
etc. times i reload the exact same page, with the exact same images in
the same buffer? if the first allocation reserved that memory and the
process has it, after killing the buffer and opening the page again, it
has plenty of free for use memory at its disposal, yet it allocates a
fresh new block of 600Mb every time. with that behaviour, i just have
to open 10 times the same page to run out of RAM in my computer. not
even firefox is that hungry.
> 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.
well, all i can say is that none of the programs i use in my linux
distribution (debian unstable), which are compiled against the same
libraries, has shown such a dramatic increase of RAM consumption in the
last months. so they seem to have optimized their allocation behaviour
very narrowly against the way i use emacs! ;)
perhaps i'll try to compile emacs using older gcc versions (up to version
27, emacs was really slim RAM-wise for me).
thanks,
jao
next prev parent reply other threads:[~2022-07-14 12:23 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-07-14 1:35 bug#56546: 29.0.50; unbounded RAM comsumption when displaying images Jose A. Ortega Ruiz
2022-07-14 5:45 ` Eli Zaretskii
2022-07-14 6:04 ` Eli Zaretskii
2022-07-14 8:53 ` Lars Ingebrigtsen
2022-07-14 9:15 ` Eli Zaretskii
2022-07-14 9:20 ` Lars Ingebrigtsen
2022-07-14 10:01 ` Lars Ingebrigtsen
2022-07-14 10:10 ` Eli Zaretskii
2022-07-14 10:15 ` Lars Ingebrigtsen
2022-07-14 12:23 ` Jose A. Ortega Ruiz [this message]
2022-07-14 16:59 ` Lars Ingebrigtsen
2022-07-14 17:26 ` Eli Zaretskii
2022-07-14 17:51 ` Glenn Morris
2022-07-14 18:08 ` Lars Ingebrigtsen
2022-07-15 23:42 ` Jose A. Ortega Ruiz
2022-07-16 10:37 ` Lars Ingebrigtsen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87h73j3mu2.fsf@mail.jao.io \
--to=mail@jao.io \
--cc=56546@debbugs.gnu.org \
--cc=eliz@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).