From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#38345: 27.0.50; Permanent increase in memory consumption after opening images (or pdfs) Date: Thu, 05 Dec 2019 16:52:33 +0200 Message-ID: <83h82ej03y.fsf@gnu.org> References: <87sgme1ww7.fsf@yantar92-laptop.i-did-not-set--mail-host-address--so-tickle-me> <83o8x0rl6d.fsf@gnu.org> <87lfs2mzo8.fsf@yantar92-laptop.i-did-not-set--mail-host-address--so-tickle-me> <87lfs19shb.fsf@mail.linkov.net> <87a78gn5k5.fsf@yantar92-laptop.i-did-not-set--mail-host-address--so-tickle-me> <83sgm8ox3g.fsf@gnu.org> <87zhgflxmc.fsf@yantar92-laptop.i-did-not-set--mail-host-address--so-tickle-me> <83lfrzq1s1.fsf@gnu.org> <87d0d7w3tt.fsf@yantar92-laptop.i-did-not-set--mail-host-address--so-tickle-me> <83zhgaloc5.fsf@gnu.org> <87zhg7jmjg.fsf@yantar92-laptop.i-did-not-set--mail-host-address--so-tickle-me> Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="27424"; mail-complaints-to="usenet@blaine.gmane.org" Cc: 38345@debbugs.gnu.org, juri@linkov.net To: Ihor Radchenko Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Thu Dec 05 15:53:16 2019 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([209.51.188.17]) by blaine.gmane.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1icsVH-0006y1-FJ for geb-bug-gnu-emacs@m.gmane.org; Thu, 05 Dec 2019 15:53:15 +0100 Original-Received: from localhost ([::1]:55838 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1icsVG-0005ES-AM for geb-bug-gnu-emacs@m.gmane.org; Thu, 05 Dec 2019 09:53:14 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:35287) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1icsV7-0005EI-0j for bug-gnu-emacs@gnu.org; Thu, 05 Dec 2019 09:53:06 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1icsV4-0002OO-Tl for bug-gnu-emacs@gnu.org; Thu, 05 Dec 2019 09:53:04 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]:37433) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1icsV4-0002NO-Hk for bug-gnu-emacs@gnu.org; Thu, 05 Dec 2019 09:53:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1icsV3-000071-VO for bug-gnu-emacs@gnu.org; Thu, 05 Dec 2019 09:53:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 05 Dec 2019 14:53:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 38345 X-GNU-PR-Package: emacs Original-Received: via spool by 38345-submit@debbugs.gnu.org id=B38345.1575557567407 (code B ref 38345); Thu, 05 Dec 2019 14:53:01 +0000 Original-Received: (at 38345) by debbugs.gnu.org; 5 Dec 2019 14:52:47 +0000 Original-Received: from localhost ([127.0.0.1]:43406 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1icsUo-00006V-R2 for submit@debbugs.gnu.org; Thu, 05 Dec 2019 09:52:47 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:52716) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1icsUm-00006G-8i for 38345@debbugs.gnu.org; Thu, 05 Dec 2019 09:52:44 -0500 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:40779) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1icsUg-0000gX-Lq; Thu, 05 Dec 2019 09:52:38 -0500 Original-Received: from [176.228.60.248] (port=2857 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1icsUf-0003P6-FX; Thu, 05 Dec 2019 09:52:38 -0500 In-reply-to: <87zhg7jmjg.fsf@yantar92-laptop.i-did-not-set--mail-host-address--so-tickle-me> (message from Ihor Radchenko on Thu, 05 Dec 2019 14:48:03 +0800) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 209.51.188.43 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.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.org gmane.emacs.bugs:172912 Archived-At: > From: Ihor Radchenko > Cc: juri@linkov.net, 38345@debbugs.gnu.org > Date: Thu, 05 Dec 2019 14:48:03 +0800 > > For the image cache data structure, I can only see one place where it > may request extra memory allocation. It is when the number of images in > the cache exceeds the size of c->images array (= c->size, which is 50 by > default). I observed memory consumption increase even when the frequency > of cache clearing in my test was <50, which makes it unclear for me > where the extra memory consumption is coming from. What you describe is the situation where Emacs enlarges the image cache because the existing cache can no longer hold all the images we currently know about. This is normal, and cannot cause a leak. The suggestion in this discussion was to expunge images from the cache more aggressively, and I thought you had difficulties in understand how this is done currently. > > I don't think replacing the system malloc on GNU/Linux systems (let > > alone on others) is an idea we'd like to pursue. You may have more > > luck playing with mallopt calls in init_alloc_once_for_pdumper > > (assuming your build defines DOUG_LEA_MALLOC). > > Do I understand correctly that you refer to emacs compiled with > alternative Doug Lea's implementation of malloc? No. AFAIK, any compilation on GNU/Linus defines DOUG_LEA_MALLOC. > Actually, I tried to find a way to compile emacs with alternative > variants of malloc, but I did not find how to do it. I don't think we support it, at least not easily. > P.S. I am running emacs with jemalloc for a few days and the overall > impression is that emacs became a lot more responsive. Previously, I > had a slow overtime degradation of delay between commands as emacs > process ran for a long time, up to the point when I can type a whole > sentence until emacs finally displays it on screen. Now, I do not see so > much degradation. This has got to be a separate issue, perhaps related to GC (do you have customizations of any GC-related variables?). It should be reported and analyzed separately, as it is unrelated to image caching.