From debbugs-submit-bounces@debbugs.gnu.org Fri Feb 24 12:00:28 2023 Received: (at submit) by debbugs.gnu.org; 24 Feb 2023 17:00:28 +0000 Received: from localhost ([127.0.0.1]:38125 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pVbQq-0003oI-4c for submit@debbugs.gnu.org; Fri, 24 Feb 2023 12:00:28 -0500 Received: from lists.gnu.org ([209.51.188.17]:41476) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pVbQn-0003o7-AH for submit@debbugs.gnu.org; Fri, 24 Feb 2023 12:00:26 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pVbQc-0006rQ-2Z for bug-gnu-emacs@gnu.org; Fri, 24 Feb 2023 12:00:14 -0500 Received: from ledu-giraud.fr ([51.159.28.247]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pVbQY-0005iu-2R for bug-gnu-emacs@gnu.org; Fri, 24 Feb 2023 12:00:13 -0500 DKIM-Signature: v=1; a=ed25519-sha256; c=simple/simple; s=ed25519; bh=UlkB9PeH zFuGl7WHEqmH7s7owxn0HaK0UC7IKwE3dw8=; h=date:subject:to:from; d=ledu-giraud.fr; b=YFxzptBLFi/4zqLKOkDNP+t9IsSaZAX8KVRMQLXVPM2sFFS7wR EQM43oBJUZufJebJcDdJ4vilO/tZ+gIMEsCg== DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; s=rsa; bh=UlkB9PeHzFuGl7WH EqmH7s7owxn0HaK0UC7IKwE3dw8=; h=date:subject:to:from; d=ledu-giraud.fr; b=ltinSxRXI2SHot72QqkyecSI2kTscwbDOlKdqp9Wu+RTpex5JF HTVUtzePsReqclwaHX5+TRhPHbABd9m2/gITZTy9m91Ibvhnb18Dxf81x4ak/1Mz+N1/u/ dIsYPy7/8sMEIfb65A58LvtW4zLgjZ7Ush5SVN83z7c0c2GKXBttTFQARkzuO7T1rcj/vF iafZAG/GNDDZza1Heq1Cax+tgtbjVvlZcn3cnPi0bwQuB3ctFhE0TlMbWd/qgPEmZwuBtY 8SZuQbAErRgT03UG/jPsMVT8dQYd3hoge0ZRqXXcd1LN8zW5TDAxJY50shFBsPdI6swrT4 W9DG+mAykoXQ== Received: from computer ( [10.1.1.1]) by ledu-giraud.fr (OpenSMTPD) with ESMTPSA id 23232d0a (TLSv1.3:TLS_AES_256_GCM_SHA384:256:NO) for ; Fri, 24 Feb 2023 18:00:03 +0100 (CET) From: Manuel Giraud To: bug-gnu-emacs@gnu.org Subject: 30.0.50; Image Cache Size growth Date: Fri, 24 Feb 2023 18:00:00 +0100 Message-ID: <87y1on9ey7.fsf@ledu-giraud.fr> MIME-Version: 1.0 Content-Type: text/plain Received-SPF: pass client-ip=51.159.28.247; envelope-from=manuel@ledu-giraud.fr; helo=ledu-giraud.fr X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-Spam-Score: -1.4 (-) X-Debbugs-Envelope-To: submit X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.4 (--) Hi, My image cache size grows really quick when browsing some images from Emacs. My recipe: emacs -Q M-: (clear-image-cache) Then, I open a image in a directory with other images. I hit 'n' 5 times (to open next 5 images). Each image is a JPG of about 1.3MiB. Then, M-x memory-report says: 366 MiB Total Image Cache Size With such growth, Emacs quickly tells me that the memory is exhausted. In GNU Emacs 30.0.50 (build 1, x86_64-unknown-openbsd7.2, cairo version 1.17.8) of 2023-02-24 built on computer Repository revision: 078cff71abc7125558ed492e894aa7d1b487d9bd Repository branch: mgi/image-dired-fix Windowing system distributor 'The X.Org Foundation', version 11.0.12101006 System Description: OpenBSD computer 7.2 GENERIC.MP#1052 amd64 Configured using: 'configure --prefix=/home/manuel/emacs --bindir=/home/manuel/bin --with-x-toolkit=no --without-sound --without-compress-install CPPFLAGS=-I/usr/local/include LDFLAGS=-L/usr/local/lib' Configured features: CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS GSETTINGS HARFBUZZ JPEG JSON LCMS2 LIBOTF LIBXML2 MODULES NOTIFY KQUEUE OLDXMENU PDUMPER PNG RSVG SQLITE3 THREADS TIFF TREE_SITTER WEBP X11 XDBE XIM XINPUT2 XPM ZLIB Important settings: value of $LC_ALL: en_US.UTF-8 locale-coding-system: utf-8-unix Major mode: Special Minor modes in effect: display-time-mode: t display-battery-mode: t server-mode: t shell-dirtrack-mode: t repeat-mode: t desktop-save-mode: t global-eldoc-mode: t show-paren-mode: t electric-indent-mode: t mouse-wheel-mode: t menu-bar-mode: t file-name-shadow-mode: t global-font-lock-mode: t font-lock-mode: t blink-cursor-mode: t buffer-read-only: t line-number-mode: t indent-tabs-mode: t transient-mark-mode: t auto-composition-mode: t auto-encryption-mode: t auto-compression-mode: t button-mode: t Load-path shadows: /home/manuel/.emacs.d/elpa/ef-themes-0.10.0/theme-loaddefs hides /home/manuel/emacs/share/emacs/30.0.50/lisp/theme-loaddefs /home/manuel/.emacs.d/elpa/transient-0.3.7/transient hides /home/manuel/emacs/share/emacs/30.0.50/lisp/transient Features: (shadow sort mail-extr emacsbug image-file image-converter dabbrev pulse memory-report org-indent reveal sh-script executable texinfo texinfo-loaddefs org-element org-persist org-id org-refile avl-tree oc-basic ol-eww ol-rmail ol-mhe ol-irc ol-info ol-gnus nnselect ol-docview ol-bibtex bibtex ol-bbdb ol-w3m ol-doi org-link-doi doc-view jka-compr vc-hg conf-mode css-mode treesit smie sgml-mode facemenu eww xdg url-queue mm-url make-mode pov-mode imenu vc-cvs vc-rcs log-view pcvs-util vc-dir ewoc image-mode exif paredit edmacro autorevert filenotify vc-git diff-mode vc bug-reference gnus-dired time battery exwm-randr xcb-randr exwm-config ido exwm exwm-input xcb-keysyms xcb-xkb exwm-manage exwm-floating xcb-cursor xcb-render exwm-layout exwm-workspace exwm-core xcb-ewmh xcb-icccm xcb xcb-xproto xcb-types xcb-debug kmacro server modus-operandi-theme modus-themes ytdious mingus libmpdee reporter edebug debug backtrace transmission color calc-bin calc-ext calc calc-loaddefs rect calc-macs w3m-load supercite regi ebdb-message ebdb-gnus gnus-msg gnus-art mm-uu mml2015 mm-view mml-smime smime gnutls dig gnus-sum shr pixel-fill kinsoku url-file svg dom gnus-group gnus-undo gnus-start gnus-dbus gnus-cloud nnimap nnmail mail-source utf7 nnoo gnus-spec gnus-int gnus-range message sendmail yank-media puny rfc822 mml mml-sec epa epg rfc6068 epg-config mm-decode mm-bodies mm-encode mail-parse rfc2231 rfc2047 rfc2045 ietf-drums gmm-utils mailheader gnus-win gnus nnheader gnus-util mail-utils range mm-util mail-prsvr ebdb-mua ebdb-com crm ebdb-format ebdb mailabbrev eieio-opt cl-extra help-mode speedbar ezimage dframe eieio-base pcase timezone org ob ob-tangle ob-ref ob-lob ob-table ob-exp org-macro org-src ob-comint org-pcomplete org-list org-footnote org-faces org-entities ob-emacs-lisp ob-core ob-eval org-cycle org-table ol org-fold org-fold-core org-keys oc org-loaddefs find-func org-version org-compat org-macs visual-basic-mode cl web-mode derived disp-table erlang-start smart-tabs-mode skeleton cc-mode cc-fonts cc-guess cc-menus cc-cmds cc-styles cc-align cc-engine cc-vars cc-defs slime-asdf grep slime-tramp tramp rx tramp-loaddefs trampver tramp-integration cus-edit cus-load wid-edit files-x tramp-compat shell pcomplete parse-time iso8601 time-date ls-lisp format-spec slime-fancy slime-indentation slime-cl-indent cl-indent slime-trace-dialog slime-fontifying-fu slime-package-fu slime-references slime-compiler-notes-tree advice slime-scratch slime-presentations bridge slime-macrostep macrostep slime-mdot-fu slime-enclosing-context slime-fuzzy slime-fancy-trace slime-fancy-inspector slime-c-p-c slime-editing-commands slime-autodoc slime-repl slime-parse slime apropos compile text-property-search etags fileloop generator xref project arc-mode archive-mode noutline outline icons pp comint ansi-osc ansi-color ring hyperspec thingatpt slime-autoloads view mule-util cal-china lunar solar cal-dst cal-bahai cal-islam cal-hebrew holidays holiday-loaddefs vc-dispatcher vc-svn appt diary-lib diary-loaddefs cal-menu calendar cal-loaddefs dired-aux dired-x dired dired-loaddefs notifications dbus xml repeat easy-mmode desktop frameset osm-autoloads rust-mode-autoloads compat-autoloads ebdb-autoloads magit-autoloads debbugs-autoloads git-commit-autoloads magit-section-autoloads ef-themes-autoloads with-editor-autoloads paredit-autoloads dash-autoloads ytdious-autoloads transmission-autoloads transient-autoloads exwm-autoloads hyperbole-autoloads detached-autoloads info package browse-url url url-proxy url-privacy url-expand url-methods url-history url-cookie generate-lisp-file url-domsuf url-util mailcap url-handlers url-parse auth-source cl-seq eieio eieio-core cl-macs password-cache json subr-x map byte-opt gv bytecomp byte-compile url-vars cl-loaddefs cl-lib rmc iso-transl tooltip cconv eldoc paren electric uniquify ediff-hook vc-hooks lisp-float-type elisp-mode mwheel term/x-win x-win term/common-win x-dnd tool-bar dnd fontset image regexp-opt fringe tabulated-list replace newcomment text-mode lisp-mode prog-mode register page tab-bar menu-bar rfn-eshadow isearch easymenu timer select scroll-bar mouse jit-lock font-lock syntax font-core term/tty-colors frame minibuffer nadvice seq simple cl-generic indonesian philippine cham georgian utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao korean japanese eucjp-ms cp51932 hebrew greek romanian slovak czech european ethiopic indian cyrillic chinese composite emoji-zwj charscript charprop case-table epa-hook jka-cmpr-hook help abbrev obarray oclosure cl-preloaded button loaddefs theme-loaddefs faces cus-face macroexp files window text-properties overlay sha1 md5 base64 format env code-pages mule custom widget keymap hashtable-print-readable backquote threads dbusbind kqueue lcms2 dynamic-setting system-font-setting font-render-setting cairo xinput2 x multi-tty make-network-process emacs) Memory information: ((conses 16 725653 31835) (symbols 48 54284 4) (strings 32 174900 22384) (string-bytes 1 5521428) (vectors 16 101351) (vector-slots 8 2135369 211753) (floats 8 1008 384) (intervals 56 28286 106) (buffers 984 120)) -- Manuel Giraud From debbugs-submit-bounces@debbugs.gnu.org Fri Feb 24 12:13:05 2023 Received: (at 61763) by debbugs.gnu.org; 24 Feb 2023 17:13:05 +0000 Received: from localhost ([127.0.0.1]:38165 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pVbd3-00049v-DP for submit@debbugs.gnu.org; Fri, 24 Feb 2023 12:13:05 -0500 Received: from eggs.gnu.org ([209.51.188.92]:40492) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pVbd1-00049O-Kv for 61763@debbugs.gnu.org; Fri, 24 Feb 2023 12:13:04 -0500 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pVbcv-0001eb-Hm; Fri, 24 Feb 2023 12:12:57 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=rOhNAQwt6Pd41APDjgxQXqugZhJS9aDWdkKQanJA9hU=; b=lm4nFV1SNyVW 4KUyo2tnaRvG4sPCpmfgkFZrVwxwQvxghFlsV1Ow81pY9Gczdx05ZDD5gHX334DQm6Xx860j3xIRM 1eF4KOGX44BtkzmbwfOThhH7+WqD8DdsepaHFlRusKy7dK3Y6LNubJtrCGN/OC8Lx4VlOsE7UgOzD CWWkCbzPlJtyxP1jdI057+Qes/TnJz7dJRHvyy2cQ7D0IqyL8py2SC4BmMFnjB6Ibgy5jr6xmjt80 2m1XIXvHvnRT37TZFRatFsXYY+5xu1/peWYuQKXda9vZCWafn/P0oc7uq9V1Y3kUkKPNJzlIlBAeM IaqJ8ADE1DaCcun5zku+fw==; Received: from [87.69.77.57] (helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pVbcg-0000Z7-6T; Fri, 24 Feb 2023 12:12:56 -0500 Date: Fri, 24 Feb 2023 19:12:43 +0200 Message-Id: <83o7pjm1h0.fsf@gnu.org> From: Eli Zaretskii To: Manuel Giraud In-Reply-To: <87y1on9ey7.fsf@ledu-giraud.fr> (bug-gnu-emacs@gnu.org) Subject: Re: bug#61763: 30.0.50; Image Cache Size growth References: <87y1on9ey7.fsf@ledu-giraud.fr> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 61763 Cc: 61763@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > Date: Fri, 24 Feb 2023 18:00:00 +0100 > From: Manuel Giraud via "Bug reports for GNU Emacs, > the Swiss army knife of text editors" > > My image cache size grows really quick when browsing some images from > Emacs. My recipe: > > emacs -Q > M-: (clear-image-cache) > Then, I open a image in a directory with other images. > I hit 'n' 5 times (to open next 5 images). > Each image is a JPG of about 1.3MiB. > Then, M-x memory-report says: > 366 MiB Total Image Cache Size > > With such growth, Emacs quickly tells me that the memory is exhausted. Did you try to lower the value of image-cache-eviction-delay? From debbugs-submit-bounces@debbugs.gnu.org Fri Feb 24 14:41:50 2023 Received: (at 61763) by debbugs.gnu.org; 24 Feb 2023 19:41:50 +0000 Received: from localhost ([127.0.0.1]:38295 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pVdx0-00086A-Hn for submit@debbugs.gnu.org; Fri, 24 Feb 2023 14:41:50 -0500 Received: from ledu-giraud.fr ([51.159.28.247]:41193) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pVdwz-000861-4k for 61763@debbugs.gnu.org; Fri, 24 Feb 2023 14:41:50 -0500 DKIM-Signature: v=1; a=ed25519-sha256; c=simple/simple; s=ed25519; bh=scVFEbc7 OgsJaP8Nlqus81RXEMaV2qEMyHYbyUaZ0Dg=; h=date:references:in-reply-to: subject:cc:to:from; d=ledu-giraud.fr; b=0Nf83bhHJGRdHb+IxulDOsztQmlqMA 5R8f+f+r5zyBakM4oJ4MM3QAN5VieFejSd5tV2N0TFplwkiQRuSx6sDA== DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; s=rsa; bh=scVFEbc7OgsJaP8N lqus81RXEMaV2qEMyHYbyUaZ0Dg=; h=date:references:in-reply-to:subject: cc:to:from; d=ledu-giraud.fr; b=cV7mKqp6HPS92B2USzZGQk78Vvg/qDZ3YfPbr+ zk0bPFSKGZU4VILwzo+dMYaaC4gLd1gnTtQmCDvYMoTepBL17jlp5HIa51IS77oa8wRPtN +IBh50P+WLxey2VrehD9m/ErBecfy3HEJyGW9PwStV8sKcmUWrqsXwocG5xB+0ebNuV6/m Xj8TBj7VSvvrAlTq5R70sdZcWqh/+lA2q36wrypHaohKhk9pAhANpDFDeOm99Ry1r7399o 8088jPsnxfNNjQ+6IjniLwsmbuVynsAOU4V/1Kj9GUVoPBZ2ySSprD/aGed9bZIr8cCIcy ZJ+98S0hbr8ht/BoiMjMydJw== Received: from computer ( [10.1.1.1]) by ledu-giraud.fr (OpenSMTPD) with ESMTPSA id e85d64c8 (TLSv1.3:TLS_AES_256_GCM_SHA384:256:NO); Fri, 24 Feb 2023 20:41:47 +0100 (CET) From: Manuel Giraud To: Eli Zaretskii Subject: Re: bug#61763: 30.0.50; Image Cache Size growth In-Reply-To: <83o7pjm1h0.fsf@gnu.org> (Eli Zaretskii's message of "Fri, 24 Feb 2023 19:12:43 +0200") References: <87y1on9ey7.fsf@ledu-giraud.fr> <83o7pjm1h0.fsf@gnu.org> Date: Fri, 24 Feb 2023 20:41:46 +0100 Message-ID: <87cz5ylukl.fsf@ledu-giraud.fr> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 61763 Cc: 61763@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Eli Zaretskii writes: [...] > Did you try to lower the value of image-cache-eviction-delay? No, it is 300. But isn't there something wrong with this growth rate? Can you reproduce (if you have time)? -- Manuel Giraud From debbugs-submit-bounces@debbugs.gnu.org Fri Feb 24 14:55:08 2023 Received: (at 61763) by debbugs.gnu.org; 24 Feb 2023 19:55:08 +0000 Received: from localhost ([127.0.0.1]:38300 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pVe9r-0008QR-V2 for submit@debbugs.gnu.org; Fri, 24 Feb 2023 14:55:08 -0500 Received: from eggs.gnu.org ([209.51.188.92]:37218) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pVe9p-0008Pr-UC for 61763@debbugs.gnu.org; Fri, 24 Feb 2023 14:55:06 -0500 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pVe9j-0001AB-TM; Fri, 24 Feb 2023 14:54:59 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=mvJryuiQUjpDc5HnzODqH0uVvf1D/jFuzSWMHoL69vI=; b=S8F6EaZ5yuN0 e86X3xqR091C2c8UxqQ+x5yVGXy2yxi6I3wF4Q+x6tBTxs178BmjMrMg7bQzxL4c7sqnGjX4lUbVU A/E1r5u27dO00ch+veCLJwCw0pZ3UjffRPV42Hi3xEjh+Ehlho1EVyusSs5lqJ5awitWflVcNPkzh xvFav1znCO6HF8CDpdYoZpo9YVdWbju1Sk0mbC9LrL83vOOEC0kNivjrvJVqQDMuzCs3hCSOsb4Ud JfJWFTtUfaK8njXeIvAlARQxIDvw0u9uqa16OSTehUp14Kg5kvXPKh84Tw0kv0OkbQJhQad3CzrSe XKc3AV2Sr7KyqhNjMgksAQ==; Received: from [87.69.77.57] (helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pVe9j-00065F-5D; Fri, 24 Feb 2023 14:54:59 -0500 Date: Fri, 24 Feb 2023 21:55:00 +0200 Message-Id: <83cz5yn8iz.fsf@gnu.org> From: Eli Zaretskii To: Manuel Giraud In-Reply-To: <87cz5ylukl.fsf@ledu-giraud.fr> (message from Manuel Giraud on Fri, 24 Feb 2023 20:41:46 +0100) Subject: Re: bug#61763: 30.0.50; Image Cache Size growth References: <87y1on9ey7.fsf@ledu-giraud.fr> <83o7pjm1h0.fsf@gnu.org> <87cz5ylukl.fsf@ledu-giraud.fr> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 61763 Cc: 61763@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Manuel Giraud > Cc: 61763@debbugs.gnu.org > Date: Fri, 24 Feb 2023 20:41:46 +0100 > > Eli Zaretskii writes: > > [...] > > > Did you try to lower the value of image-cache-eviction-delay? > > No, it is 300. But isn't there something wrong with this growth rate? Why do you think it's wrong? > Can you reproduce (if you have time)? Not sure what I need to reproduce. I've visited 6 images of 2 MiB each and Memory Report says I have 581 MiB in my image cache. Meanwhile the memory footprint of the Emacs process is 350 MiB. Is this what you wanted to see? From debbugs-submit-bounces@debbugs.gnu.org Fri Feb 24 15:27:46 2023 Received: (at 61763) by debbugs.gnu.org; 24 Feb 2023 20:27:46 +0000 Received: from localhost ([127.0.0.1]:38330 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pVefS-0000m5-HG for submit@debbugs.gnu.org; Fri, 24 Feb 2023 15:27:46 -0500 Received: from ledu-giraud.fr ([51.159.28.247]:45371) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pVefQ-0000ls-1Q for 61763@debbugs.gnu.org; Fri, 24 Feb 2023 15:27:45 -0500 DKIM-Signature: v=1; a=ed25519-sha256; c=simple/simple; s=ed25519; bh=G68OOTX5 VuI/nXykl0Y00j/CBxda0ZA1k6wIBECQuDI=; h=date:references:in-reply-to: subject:cc:to:from; d=ledu-giraud.fr; b=uAOp2JV7kuvuuxdRqfCqaxvgIQLylv OOyg6jxkwNbXQif0o6l0/vpTCR7blBFrhzyVFOpfKtMZ3wGVU2OsLlBQ== DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; s=rsa; bh=G68OOTX5VuI/nXyk l0Y00j/CBxda0ZA1k6wIBECQuDI=; h=date:references:in-reply-to:subject: cc:to:from; d=ledu-giraud.fr; b=Lhs6rbWlLByB6umkVoucpB79FH7y2PEi9X6i+f cngRx0bYgTh5bJ5h4k2eNVrirfz9o8HTwlhbW7GEKM7AfkCaFHrYbNGNEPbFntOAWMxU77 e6Jf6JZfNw3AOueQX3WPW3cuoD9yfruV7/0blUegVsIZb6tRItstV6F8hSSkwrjDZuK9f1 1+2gGSEBq+AaDaPq6+Cuv5k5VlX1TKlsqVavmIBKrdMz7LceYz6nD4b1kT6ntUXuJc12Xz nsdxmJU+o6TfeNdzXKIkbaNdK9Q7AH1d02mJbaLfEFOcLtIe/9fZcm+S8BIBlkjGvfJzcw gE4lbnm8KqIYRWKg7a97KzMw== Received: from computer ( [10.1.1.1]) by ledu-giraud.fr (OpenSMTPD) with ESMTPSA id 21c5616b (TLSv1.3:TLS_AES_256_GCM_SHA384:256:NO); Fri, 24 Feb 2023 21:27:42 +0100 (CET) From: Manuel Giraud To: Eli Zaretskii Subject: Re: bug#61763: 30.0.50; Image Cache Size growth In-Reply-To: <83cz5yn8iz.fsf@gnu.org> (Eli Zaretskii's message of "Fri, 24 Feb 2023 21:55:00 +0200") References: <87y1on9ey7.fsf@ledu-giraud.fr> <83o7pjm1h0.fsf@gnu.org> <87cz5ylukl.fsf@ledu-giraud.fr> <83cz5yn8iz.fsf@gnu.org> Date: Fri, 24 Feb 2023 21:27:41 +0100 Message-ID: <878rgmlsg2.fsf@ledu-giraud.fr> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 61763 Cc: 61763@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Eli Zaretskii writes: [...] >> Can you reproduce (if you have time)? > > Not sure what I need to reproduce. I've visited 6 images of 2 MiB > each and Memory Report says I have 581 MiB in my image cache. > Meanwhile the memory footprint of the Emacs process is 350 MiB. Is > this what you wanted to see? Ok. So in the same ballpark. I thought there was something wrong on my setup. Why I think this growth is wrong is because it seems high. And if I'm browsing some images in Emacs, I'm getting a "Memory exhausted (restart Emacs)" message after only 20 or 30 images. -- Manuel Giraud From debbugs-submit-bounces@debbugs.gnu.org Fri Feb 24 15:43:18 2023 Received: (at 61763) by debbugs.gnu.org; 24 Feb 2023 20:43:18 +0000 Received: from localhost ([127.0.0.1]:38342 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pVeuU-0001BW-D2 for submit@debbugs.gnu.org; Fri, 24 Feb 2023 15:43:18 -0500 Received: from eggs.gnu.org ([209.51.188.92]:59212) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pVeuS-0001BJ-BB for 61763@debbugs.gnu.org; Fri, 24 Feb 2023 15:43:16 -0500 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pVeuM-0000dW-DD; Fri, 24 Feb 2023 15:43:10 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=+DJdp99q8hLKb1yb3XEzisdVhOgofYv2vu6r+MCZuv8=; b=sCTsioWEZFgG DCwadH3uzOgkJkX6QqU8zjn79YbX4L+BofvUyo4boIDeVhSHuFvjU8mXTtfRa1aYYkvgzq/jUaFJy Vm8lS5X/6hlU+7dbRrv7pf3fHC1TcsDNcWupdlnUlRzAP4ByIezXlhLLGjNelTqC10PHNLm3JBuPS JeW/HcGsJj/AVV9x+TILoE+Gxor12bKqKBGBluanPJv//9K5KcP9vms/1mNA7dJN+dlgZRa5HNDKt YmiE54rIHl7KxbA2ZifaddYbRYJsbbvKWOXYe4YFXyNhY6Knh1b1ug6ruvn+yRG16wWYmZrbrAsTX Ooi0XNSd37dzxqfXdOgtWg==; Received: from [87.69.77.57] (helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pVeuL-0005GP-NG; Fri, 24 Feb 2023 15:43:10 -0500 Date: Fri, 24 Feb 2023 22:43:10 +0200 Message-Id: <837cw6n6ap.fsf@gnu.org> From: Eli Zaretskii To: Manuel Giraud In-Reply-To: <878rgmlsg2.fsf@ledu-giraud.fr> (message from Manuel Giraud on Fri, 24 Feb 2023 21:27:41 +0100) Subject: Re: bug#61763: 30.0.50; Image Cache Size growth References: <87y1on9ey7.fsf@ledu-giraud.fr> <83o7pjm1h0.fsf@gnu.org> <87cz5ylukl.fsf@ledu-giraud.fr> <83cz5yn8iz.fsf@gnu.org> <878rgmlsg2.fsf@ledu-giraud.fr> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 61763 Cc: 61763@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Manuel Giraud > Cc: 61763@debbugs.gnu.org > Date: Fri, 24 Feb 2023 21:27:41 +0100 > > Eli Zaretskii writes: > > [...] > > >> Can you reproduce (if you have time)? > > > > Not sure what I need to reproduce. I've visited 6 images of 2 MiB > > each and Memory Report says I have 581 MiB in my image cache. > > Meanwhile the memory footprint of the Emacs process is 350 MiB. Is > > this what you wanted to see? > > Ok. So in the same ballpark. I thought there was something wrong on my > setup. > > Why I think this growth is wrong is because it seems high. And if I'm > browsing some images in Emacs, I'm getting a "Memory exhausted (restart > Emacs)" message after only 20 or 30 images. JPEG compression is very good, it routinely compresses images with ratios of 10:1 to 20:1. If I use djpeg to convert the 2 MiB images I used into BMP, I get 36 MiB BMP files -- that's a 1:18 expansion ratio. And Emacs converts each image to a pixmap for display, which is basically similar to what I did. Multiply that by 20 or 30, and you get the numbers you see, I think. The solution is to enlarge the VM for your machine (by enlarging swap, for example). If you don't keep those images displayed in windows, lowering image-cache-eviction-delay might also help. From debbugs-submit-bounces@debbugs.gnu.org Fri Feb 24 16:32:56 2023 Received: (at 61763) by debbugs.gnu.org; 24 Feb 2023 21:32:56 +0000 Received: from localhost ([127.0.0.1]:38392 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pVfgV-0002er-MK for submit@debbugs.gnu.org; Fri, 24 Feb 2023 16:32:55 -0500 Received: from ledu-giraud.fr ([51.159.28.247]:31274) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pVfgT-0002eg-Es for 61763@debbugs.gnu.org; Fri, 24 Feb 2023 16:32:54 -0500 DKIM-Signature: v=1; a=ed25519-sha256; c=simple/simple; s=ed25519; bh=PhJ9x1sc jaDxP2V0Bf7dxP5KfGsNGJOi6mCDE90FHpA=; h=date:references:in-reply-to: subject:cc:to:from; d=ledu-giraud.fr; b=biwfbAlZ56w2JjoDblOhsIBglnyTh9 XADqdU68XsSwBOk3srvGX7U84J03a8wAUSMhHiiPoY+78bq9/Yo0DSCw== DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; s=rsa; bh=PhJ9x1scjaDxP2V0 Bf7dxP5KfGsNGJOi6mCDE90FHpA=; h=date:references:in-reply-to:subject: cc:to:from; d=ledu-giraud.fr; b=eA1Bg5Q4GQFlidDtIevZqxQ0xC+1hQ+S9pA4JO FRO7pBVCV4WcRX8ws4lE69CLrDxiNufXj1EBss9R5YBAxuHFVX0vqm5C2QOQkSn+4Z+He5 cmHrD4vvioZPz2CmdGXb30pPf2ztzPSuCW3BXN8ZC3b6OzfHAPURnadKZZcFOKM3k6qGWC zliJNR96NSdw4loG7W80bmTgUb1HCGn1ddKN88qozSLPw74f8XFWHcPzd2vXKe61Zhv9im yQLuySRXHKT1hT29eFHsq6YgTZxWKkFYffMGqYtEBWEg6GLJo+ji5EhfV6eP0QaI9vt8nF cFzg6ReA6eI0BBp+CcSv+5oQ== Received: from computer ( [10.1.1.1]) by ledu-giraud.fr (OpenSMTPD) with ESMTPSA id f91552bd (TLSv1.3:TLS_AES_256_GCM_SHA384:256:NO); Fri, 24 Feb 2023 22:32:51 +0100 (CET) From: Manuel Giraud To: Eli Zaretskii Subject: Re: bug#61763: 30.0.50; Image Cache Size growth In-Reply-To: <837cw6n6ap.fsf@gnu.org> (Eli Zaretskii's message of "Fri, 24 Feb 2023 22:43:10 +0200") References: <87y1on9ey7.fsf@ledu-giraud.fr> <83o7pjm1h0.fsf@gnu.org> <87cz5ylukl.fsf@ledu-giraud.fr> <83cz5yn8iz.fsf@gnu.org> <878rgmlsg2.fsf@ledu-giraud.fr> <837cw6n6ap.fsf@gnu.org> Date: Fri, 24 Feb 2023 22:32:49 +0100 Message-ID: <874jralpfi.fsf@ledu-giraud.fr> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 61763 Cc: 61763@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Eli Zaretskii writes: [...] > JPEG compression is very good, it routinely compresses images with > ratios of 10:1 to 20:1. If I use djpeg to convert the 2 MiB images I > used into BMP, I get 36 MiB BMP files -- that's a 1:18 expansion > ratio. And Emacs converts each image to a pixmap for display, which > is basically similar to what I did. Multiply that by 20 or 30, and > you get the numbers you see, I think. Yes, one of the images I'm using is 3264 by 2448 pixels times 3 octets (RGB, I guess) and we get about 23MiB... so those numbers seems ok. > The solution is to enlarge the VM for your machine (by enlarging swap, > for example). If you don't keep those images displayed in windows, > lowering image-cache-eviction-delay might also help. In image.c line 2079, there is already a mecanism to automatically lower this delay if the cache has grown large (so I think we're covered here). But OTOH, at line 3010, we can see that this cache will grow no matter what. Maybe we should have parameter (maybe a custom) that limit this growth up to a certain point and then start uncaching older images. WDYT? -- Manuel Giraud From debbugs-submit-bounces@debbugs.gnu.org Sat Feb 25 02:09:43 2023 Received: (at 61763) by debbugs.gnu.org; 25 Feb 2023 07:09:43 +0000 Received: from localhost ([127.0.0.1]:38865 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pVogg-0002Y3-W6 for submit@debbugs.gnu.org; Sat, 25 Feb 2023 02:09:43 -0500 Received: from eggs.gnu.org ([209.51.188.92]:57768) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pVoge-0002Xm-Uz for 61763@debbugs.gnu.org; Sat, 25 Feb 2023 02:09:41 -0500 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pVogZ-0004eJ-GF; Sat, 25 Feb 2023 02:09:35 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=jsbRDrQvffeyjKKdH09xqkas/8UeqdRp2VA7/RtC5yk=; b=EMu6KGD6jvS9 tnmsYIithyPxjnAqSTouPkHiHPCHk4xelKnOa59+RXFab+17J5hxiSktOpr4o11VTJUzLju7HmouI 26rrVa8Km2SjlCQNEtXZbE9x41aXzxKR/mxdz96/8VyVFGaQk0SvANqKPECCQtedbrY/QLqR/nI4i N+7jpUqGlogSrAKYgCqiNylirZUSIs2Wp3rZhVql6OSC9ErIae0+ctDg3z6KZPM0oYTJk/GWYxGvo S7rR2gBcgVO+0QrjcaH0Ig6K512GhV+Xz5/agkPcafCPB/qucaXK04YMgV9TU4IDqeOQoZWgeQFgS Rssn6koo48OTvD6jj94KQA==; Received: from [87.69.77.57] (helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pVogX-0003Ir-3N; Sat, 25 Feb 2023 02:09:34 -0500 Date: Sat, 25 Feb 2023 09:09:35 +0200 Message-Id: <83wn46kyq8.fsf@gnu.org> From: Eli Zaretskii To: Manuel Giraud In-Reply-To: <874jralpfi.fsf@ledu-giraud.fr> (message from Manuel Giraud on Fri, 24 Feb 2023 22:32:49 +0100) Subject: Re: bug#61763: 30.0.50; Image Cache Size growth References: <87y1on9ey7.fsf@ledu-giraud.fr> <83o7pjm1h0.fsf@gnu.org> <87cz5ylukl.fsf@ledu-giraud.fr> <83cz5yn8iz.fsf@gnu.org> <878rgmlsg2.fsf@ledu-giraud.fr> <837cw6n6ap.fsf@gnu.org> <874jralpfi.fsf@ledu-giraud.fr> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 61763 Cc: 61763@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Manuel Giraud > Cc: 61763@debbugs.gnu.org > Date: Fri, 24 Feb 2023 22:32:49 +0100 > > Eli Zaretskii writes: > > [...] > > > JPEG compression is very good, it routinely compresses images with > > ratios of 10:1 to 20:1. If I use djpeg to convert the 2 MiB images I > > used into BMP, I get 36 MiB BMP files -- that's a 1:18 expansion > > ratio. And Emacs converts each image to a pixmap for display, which > > is basically similar to what I did. Multiply that by 20 or 30, and > > you get the numbers you see, I think. > > Yes, one of the images I'm using is 3264 by 2448 pixels times 3 octets > (RGB, I guess) and we get about 23MiB... so those numbers seems ok. > > > The solution is to enlarge the VM for your machine (by enlarging swap, > > for example). If you don't keep those images displayed in windows, > > lowering image-cache-eviction-delay might also help. > > In image.c line 2079, there is already a mecanism to automatically lower > this delay if the cache has grown large (so I think we're covered here). But that happens when the number of cached images is above 40, and you are saying you have problems with memory before that. Also, the limit of 40 images is _per_frame_, so if you show images in separate frames, the automatic lowering will happen later, if at all. > But OTOH, at line 3010, we can see that this cache will grow no matter > what. That's not what happens at line 3010. There, we enlarge the number of available slots in the cache, but not the number of cached images. The memory taken by the cache itself is very small compared to the memory used by the images. > Maybe we should have parameter (maybe a custom) that limit this > growth up to a certain point and then start uncaching older images. > WDYT? We cannot uncache an image that is being displayed in some window. Doing so would immediately cause a crash on the next redisplay cycle. So lowering the eviction delay is the mechanism you should use, assuming it helps in your use case. Did you try that, and if you did, did it help? For how much time do you display each image before you discard its buffer or delete its window? From debbugs-submit-bounces@debbugs.gnu.org Sat Feb 25 07:19:26 2023 Received: (at 61763) by debbugs.gnu.org; 25 Feb 2023 12:19:26 +0000 Received: from localhost ([127.0.0.1]:39312 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pVtWQ-00032A-AO for submit@debbugs.gnu.org; Sat, 25 Feb 2023 07:19:26 -0500 Received: from ledu-giraud.fr ([51.159.28.247]:7891) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pVtWN-000320-Pw for 61763@debbugs.gnu.org; Sat, 25 Feb 2023 07:19:24 -0500 DKIM-Signature: v=1; a=ed25519-sha256; c=simple/simple; s=ed25519; bh=wmslcZlV JqaUmJ39QTxTJxvE07wbGE8Bbax2gUMCzJE=; h=date:references:in-reply-to: subject:cc:to:from; d=ledu-giraud.fr; b=ml2xwCaWK31kh5RYsV4iLExKiqM9MM 1dDGJgnWNqenaWTE1aWpO8+mh6zrRwSRtqjtgdzIYXXgqFghmIQL5bDg== DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; s=rsa; bh=wmslcZlVJqaUmJ39 QTxTJxvE07wbGE8Bbax2gUMCzJE=; h=date:references:in-reply-to:subject: cc:to:from; d=ledu-giraud.fr; b=17p4gtYr+xWx8i8RvWbM8G9OflfmBx6F770JiZ kWe6mtf0hZ5pHwG6OwQHHCz9n/4XmUQKjdv/DmP+53k/hsNxdxtyuOrtzWhE2AevVHqk7e NHsjnw5438x+7jUCs5ValGcVQ4afMlSL70ywUeQ+o8BDQW/EXcSyZbpnV0lwPkf5lQA0+u pe8BrOAWyeMJbYUkWYkQv3tmNILr/9PVVp7jlrNgPqXyFys9hKR8jggvon1/M3eQHpiTYP apYXpBX9UtSb8cBOGs9/QjZIotPELzdiE3x6D2iEEQZcCqYiWcFUaE2D9rwh03FELujcvL LaS/T1Pz+yss60fDOyQ+kUAw== Received: from computer (82-65-148-221.subs.proxad.net [82.65.148.221]) by ledu-giraud.fr (OpenSMTPD) with ESMTPSA id 35fe9bc3 (TLSv1.3:TLS_AES_256_GCM_SHA384:256:NO); Sat, 25 Feb 2023 13:19:22 +0100 (CET) From: Manuel Giraud To: Eli Zaretskii Subject: Re: bug#61763: 30.0.50; Image Cache Size growth In-Reply-To: <83wn46kyq8.fsf@gnu.org> (Eli Zaretskii's message of "Sat, 25 Feb 2023 09:09:35 +0200") References: <87y1on9ey7.fsf@ledu-giraud.fr> <83o7pjm1h0.fsf@gnu.org> <87cz5ylukl.fsf@ledu-giraud.fr> <83cz5yn8iz.fsf@gnu.org> <878rgmlsg2.fsf@ledu-giraud.fr> <837cw6n6ap.fsf@gnu.org> <874jralpfi.fsf@ledu-giraud.fr> <83wn46kyq8.fsf@gnu.org> Date: Sat, 25 Feb 2023 13:19:20 +0100 Message-ID: <87pm9ydjjr.fsf@ledu-giraud.fr> MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 61763 Cc: 61763@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Eli Zaretskii writes: [...] >> Maybe we should have parameter (maybe a custom) that limit this >> growth up to a certain point and then start uncaching older images. >> WDYT? > > We cannot uncache an image that is being displayed in some window. > Doing so would immediately cause a crash on the next redisplay cycle. > So lowering the eviction delay is the mechanism you should use, > assuming it helps in your use case. Did you try that, and if you did, > did it help? For how much time do you display each image before you > discard its buffer or delete its window? I've try with image-cache-eviction-delay at 30 seconds and I never exceed 700MiB as Image Cache and never hit a "Memory exhausted". So this is solved for this use case. Thanks for your patience Eli! -- Manuel Giraud From debbugs-submit-bounces@debbugs.gnu.org Sat Feb 25 08:24:18 2023 Received: (at 61763-done) by debbugs.gnu.org; 25 Feb 2023 13:24:18 +0000 Received: from localhost ([127.0.0.1]:39341 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pVuXB-00078C-Nj for submit@debbugs.gnu.org; Sat, 25 Feb 2023 08:24:17 -0500 Received: from eggs.gnu.org ([209.51.188.92]:47926) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pVuXA-00077x-1u for 61763-done@debbugs.gnu.org; Sat, 25 Feb 2023 08:24:16 -0500 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pVuX4-0008II-IE; Sat, 25 Feb 2023 08:24:10 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=R29yXlehguWXCyjm+t4KZkjV2qOwQ3HASueEQRMuic0=; b=hP1DkoPnlKOX FNQNTNHGIIpayTOD9xMQ9/iX5vt7oKfdDzJpgZlRfVuQEiJ7zdr0RYrkDP6gCLm55+QxNHVIAgs38 np7pPJ+HzdD5J13AdBJ1pwMZRlZ3609MIouzdS5ypMhtHPrga0q4DOSxGWF5za92kWwzZYpcitWHo Qukbd+347emXVj6CXMR4U+Sq5NUsXFA2fwkM+W03GTyAJPyXKuhq7D+gqVBadTsMGb40SZCYP9KuC WZmq6AXMrTAZkbfZHKY6K6C3TuKs+3L/9izXFH6JVgfIHD3uLx9t7BeuYdf1sugHs0bqxrnrVOzfu JjazgCwX/bPY1gWbzyVFUg==; Received: from [87.69.77.57] (helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pVuX3-00040E-PA; Sat, 25 Feb 2023 08:24:10 -0500 Date: Sat, 25 Feb 2023 15:24:10 +0200 Message-Id: <837cw5lvyd.fsf@gnu.org> From: Eli Zaretskii To: Manuel Giraud In-Reply-To: <87pm9ydjjr.fsf@ledu-giraud.fr> (message from Manuel Giraud on Sat, 25 Feb 2023 13:19:20 +0100) Subject: Re: bug#61763: 30.0.50; Image Cache Size growth References: <87y1on9ey7.fsf@ledu-giraud.fr> <83o7pjm1h0.fsf@gnu.org> <87cz5ylukl.fsf@ledu-giraud.fr> <83cz5yn8iz.fsf@gnu.org> <878rgmlsg2.fsf@ledu-giraud.fr> <837cw6n6ap.fsf@gnu.org> <874jralpfi.fsf@ledu-giraud.fr> <83wn46kyq8.fsf@gnu.org> <87pm9ydjjr.fsf@ledu-giraud.fr> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 61763-done Cc: 61763-done@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Manuel Giraud > Cc: 61763@debbugs.gnu.org > Date: Sat, 25 Feb 2023 13:19:20 +0100 > > Eli Zaretskii writes: > > [...] > > >> Maybe we should have parameter (maybe a custom) that limit this > >> growth up to a certain point and then start uncaching older images. > >> WDYT? > > > > We cannot uncache an image that is being displayed in some window. > > Doing so would immediately cause a crash on the next redisplay cycle. > > So lowering the eviction delay is the mechanism you should use, > > assuming it helps in your use case. Did you try that, and if you did, > > did it help? For how much time do you display each image before you > > discard its buffer or delete its window? > > I've try with image-cache-eviction-delay at 30 seconds and I never > exceed 700MiB as Image Cache and never hit a "Memory exhausted". So > this is solved for this use case. Thanks for your patience Eli! Thanks, I'm therefore closing this bug. From unknown Mon Jun 23 14:58:44 2025 Received: (at fakecontrol) by fakecontrolmessage; To: internal_control@debbugs.gnu.org From: Debbugs Internal Request Subject: Internal Control Message-Id: bug archived. Date: Sun, 26 Mar 2023 11:24:08 +0000 User-Agent: Fakemail v42.6.9 # This is a fake control message. # # The action: # bug archived. thanks # This fakemail brought to you by your local debbugs # administrator