From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Stefan Kangas Newsgroups: gmane.emacs.bugs Subject: bug#51763: 27.2; Displaying many images take all memory Date: Thu, 11 Nov 2021 01:50:59 -0800 Message-ID: References: <87wnlfrriv.fsf@posteo.net> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="4164"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) Cc: 51763@debbugs.gnu.org To: Thierry Volpiatto Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Thu Nov 11 10:52:09 2021 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 1ml6kb-0000oI-6I for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 11 Nov 2021 10:52:09 +0100 Original-Received: from localhost ([::1]:34636 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ml6ka-0004UE-6f for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 11 Nov 2021 04:52:08 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:33330) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ml6kU-0004Tn-3W for bug-gnu-emacs@gnu.org; Thu, 11 Nov 2021 04:52:02 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]:56877) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1ml6kT-00087e-Rd for bug-gnu-emacs@gnu.org; Thu, 11 Nov 2021 04:52:01 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1ml6kT-0003cC-R0 for bug-gnu-emacs@gnu.org; Thu, 11 Nov 2021 04:52:01 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Stefan Kangas Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 11 Nov 2021 09:52:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 51763 X-GNU-PR-Package: emacs Original-Received: via spool by 51763-submit@debbugs.gnu.org id=B51763.163662427013820 (code B ref 51763); Thu, 11 Nov 2021 09:52:01 +0000 Original-Received: (at 51763) by debbugs.gnu.org; 11 Nov 2021 09:51:10 +0000 Original-Received: from localhost ([127.0.0.1]:40190 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ml6je-0003ap-6O for submit@debbugs.gnu.org; Thu, 11 Nov 2021 04:51:10 -0500 Original-Received: from mail-pl1-f172.google.com ([209.85.214.172]:39530) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ml6jZ-0003aH-Pk for 51763@debbugs.gnu.org; Thu, 11 Nov 2021 04:51:09 -0500 Original-Received: by mail-pl1-f172.google.com with SMTP id t21so5346117plr.6 for <51763@debbugs.gnu.org>; Thu, 11 Nov 2021 01:51:05 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:in-reply-to:references:user-agent :mime-version:date:message-id:subject:to:cc; bh=OrHwgp1uhd1X1ndyy1pqLet7n4fTW3RAFReTQiOXvQw=; b=cAqt9v/ZbiH68IiyhINnDim+60txgqZavtOYEvjnDgarlYq+vNavYWKDvudeLBKobn z5YYyTQOeKNrtZKFpx4GjX4ZzcgrSTliWxP/2TIY/CB+xjBGbgZa3k0hLMTda6455SQk E+UMLcn7WKUqEdfSwnqBAMBx6V6x5esjs0xkHQKv/fyTs5hb/6rIOQutURUWXyPkvPau j54n7GoZIrrNtf7k+I4osNnx3wifD2T12JLJrRGD9bXbTYAmuz1VAzGoK97VbZFF6KN1 f8sXloCEyKuGg/xetGFYj7P91dxaCJvhceWPIpfI0BRyt5EHOpnBlyKxteDUuoO1UtME ftPw== X-Gm-Message-State: AOAM531xRnFntDbRsF+Ht/W4bPBvG27ibyo9VPSyTC2RQx9UxUoUYLmd +0gbVAI4o/diAzCwKGuvzNOyGOiqsbohzEl2gmR8WEJi X-Google-Smtp-Source: ABdhPJyhSRX6jank4PFYNXwKev2jQNt2aq9aYYn4tM4CemScTPhoV4vdwL3NFvAawbJquy3HDQcPKF1s8A4tF66KEUc= X-Received: by 2002:a17:90a:be10:: with SMTP id a16mr6667636pjs.133.1636624259826; Thu, 11 Nov 2021 01:50:59 -0800 (PST) Original-Received: from 753933720722 named unknown by gmailapi.google.com with HTTPREST; Thu, 11 Nov 2021 01:50:59 -0800 In-Reply-To: <87wnlfrriv.fsf@posteo.net> (Thierry Volpiatto's message of "Thu, 11 Nov 2021 09:00:31 +0000") 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:219616 Archived-At: Thierry Volpiatto writes: > I see you changed image-dired to use image-mode in emacs-29 instead of using like > before image-magick. That's fine I used the same approach two years ago > in Helm, but switched back quickly to image-dired because it was taking > all memory and it was not recoverable until I kill emacs. I thought it > was my fault but I see new image-dired in emacs-29 have same problem: > > 1) emacs -Q > 2) Open a large image directory with dired > 3) Open files one by one with C-t i until memory is full (use f3 C-t i > C-n f4 etc...). Memory starts to grow seriously after around 70 files > for me. > > Killing the image-dired buffer changes nothing, I have to restart emacs > to recover memory. Thanks for the bug report! In principle there should be no difference between the two: in both cases we need to cache the same upscaled image. However, we currently have an issue with our built-in image scaling that we cache the image both before resizing and after. I suspect that this is the explanation for the higher memory usage you see. See this comment in `image--scale-within-limits-p': ;; Note: `image-size' looks up and thus caches the ;; untransformed image. There's no easy way to ;; prevent that. and the relevant code in image.c that verifies this. I believe that we could fix this in image.c. I don't think it's necessarily very hard, but it does take some coding. However, I'm curious what you mean when you say that it "never" frees the memory. What happens if you set `image-cache-eviction-delay' to some very low value like 5 seconds? AFAIU, calling `clear-image-cache' should also the free memory unless we have a memory leak. You could also call this function from your code. Does calling this function free the memory for you?