From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: "Jose A. Ortega Ruiz" Newsgroups: gmane.emacs.bugs Subject: bug#56546: 29.0.50; unbounded RAM comsumption when displaying images Date: Sat, 16 Jul 2022 00:42:16 +0100 Message-ID: <87r12mhrjb.fsf@mail.jao.io> References: <87cze84gst.fsf@mail.jao.io> <874jzjbpg7.fsf@gnus.org> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="2606"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) Cc: 56546@debbugs.gnu.org To: Lars Ingebrigtsen Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sat Jul 16 01:43:34 2022 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1oCUy6-0000Xj-La for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 16 Jul 2022 01:43:34 +0200 Original-Received: from localhost ([::1]:34748 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oCUy5-0007Yt-F6 for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 15 Jul 2022 19:43:33 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:37112) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oCUxb-0007XR-1v for bug-gnu-emacs@gnu.org; Fri, 15 Jul 2022 19:43:03 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:44637) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1oCUxa-0005RR-47 for bug-gnu-emacs@gnu.org; Fri, 15 Jul 2022 19:43:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1oCUxZ-0005AU-NF for bug-gnu-emacs@gnu.org; Fri, 15 Jul 2022 19:43:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: "Jose A. Ortega Ruiz" Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 15 Jul 2022 23:43:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 56546 X-GNU-PR-Package: emacs Original-Received: via spool by 56546-submit@debbugs.gnu.org id=B56546.165792854719820 (code B ref 56546); Fri, 15 Jul 2022 23:43:01 +0000 Original-Received: (at 56546) by debbugs.gnu.org; 15 Jul 2022 23:42:27 +0000 Original-Received: from localhost ([127.0.0.1]:42396 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oCUx1-00059c-7P for submit@debbugs.gnu.org; Fri, 15 Jul 2022 19:42:27 -0400 Original-Received: from relay11.mail.gandi.net ([217.70.178.231]:48459) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oCUwy-00059O-Tu for 56546@debbugs.gnu.org; Fri, 15 Jul 2022 19:42:25 -0400 Original-Received: (Authenticated sender: mail@jao.io) by mail.gandi.net (Postfix) with ESMTPSA id B9CE4100004; Fri, 15 Jul 2022 23:42:17 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jao.io; s=gm1; t=1657928538; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=XWMfLbIgArugcqsBb1ZK6MyFKYxarbTOI78h+29+Kms=; b=erSh0BMN/KdfH1ja4M7pzYqEaESPQLmqNGGYDj9rkTeF9gu5EdXs1ZlEG6ntGXQSEIlcuF 6BRKNuzhmyHZw9rA60Md0gTYJ9+3ACP9OAWQWiRv5WwO/o182et/JKLV0KGERtUe7tMUeI BYyY7Mw9RqKQ62hD5ccduubTwbR5MWBfmI2g2Jb7b7McAQqkab81YzC1GojHfB4tAF2Sih D6FmrweYEvE0M49LyULNtql0wrZXhbPtsfmbUaZh9Z7d7MsKttVt2nYZLKY05ieWQ17d5h F2woEQMNlMqD2Lr/Ab3Vop0ZijZBb5KDzkkCl3Kck2hrWNKbuPyf+juC42lH0A== Original-Received: from localhost (rivendell.localdomain [local]) by rivendell.localdomain (OpenSMTPD) with ESMTPA id fd8013be; Fri, 15 Jul 2022 23:42:16 +0000 (UTC) In-Reply-To: <874jzjbpg7.fsf@gnus.org> (Lars Ingebrigtsen's message of "Thu, 14 Jul 2022 18:59:20 +0200") X-Attribution: jao X-Clacks-Overhead: GNU Terry Pratchett X-URL: X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.io gmane.emacs.bugs:237129 Archived-At: On Thu, Jul 14 2022, Lars Ingebrigtsen wrote: > "Jose A. Ortega Ruiz" writes: > >> - 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 > > I think this should all be fixed on the current trunk now -- can you > check? Yes, it essentially does. Only the first jump to ~630Mb happens, and then memory stays there after repeated reloads. If i do it often (or quickly, i think) enough i can make it occasionally jump to the ~1200Mb mark, but for instance cleaning the image cache makes it go back to ~600Mb (so there are clearly situations where big chunks of memory do get released back to the system, thankfully). So i think you did fix the problem, thanks a lot Lars! While we're here, i was inspecting the image-cache-size during the reloads of the page, and i saw every reload increases that size by about 30Mb (then it will eventually go down as old images are released)... given that, the big initial jump of ~500Mb in RAM consumption surprises me a little, but i see reasons why it can be completely normal for some initial allocation (and how it might be staying there because of libgcc policies). I was also naively expecting that, given that i'm reloading the same page with the "same" images, they'd be found in the cache the second and subsequent times, but, since the cache size increases, i see that they're not considered the "same" by the caching mechanism; i can again see reasons for that behaviour (i am sure the cache is not judging image equality using "image urls"), just mentioning it in case it's unexpected or there's an easy way of reusing the cached images). Anyway, thanks a lot for bearing with me and solving the problem: this bug is all but fixed now from my point of view. Cheers, jao -- That's a high price to pay for a theoretically inelegant misfeature that's seldom used correctly in portable code. -Will Clinger, r6rs-discuss mailing list