From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Memory usage report Date: Fri, 18 Sep 2020 15:40:40 +0300 Message-ID: <83pn6j45rr.fsf@gnu.org> References: <87lfh8kyot.fsf@gnus.org> <83k0ws5hzt.fsf@gnu.org> <87h7rwkxtk.fsf@gnus.org> <83imcb61p7.fsf@gnu.org> <871rizl5mf.fsf@gnus.org> <83r1qz48h3.fsf@gnu.org> <871rizjogr.fsf@gnus.org> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="10189"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel@gnu.org To: Lars Ingebrigtsen Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Fri Sep 18 14:41:22 2020 Return-path: Envelope-to: ged-emacs-devel@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 1kJFhZ-0002YP-PS for ged-emacs-devel@m.gmane-mx.org; Fri, 18 Sep 2020 14:41:21 +0200 Original-Received: from localhost ([::1]:53228 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kJFhY-0003wu-QK for ged-emacs-devel@m.gmane-mx.org; Fri, 18 Sep 2020 08:41:20 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:34030) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kJFgi-0003C6-9x for emacs-devel@gnu.org; Fri, 18 Sep 2020 08:40:29 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:46020) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kJFgh-0004Y8-Sy; Fri, 18 Sep 2020 08:40:27 -0400 Original-Received: from [176.228.60.248] (port=1144 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1kJFgh-0005FV-0m; Fri, 18 Sep 2020 08:40:27 -0400 In-Reply-To: <871rizjogr.fsf@gnus.org> (message from Lars Ingebrigtsen on Fri, 18 Sep 2020 13:47:48 +0200) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:256078 Archived-At: > From: Lars Ingebrigtsen > Cc: emacs-devel@gnu.org > Date: Fri, 18 Sep 2020 13:47:48 +0200 > > >> But for this command to be useful in general, I think we'll have to > >> expose more data from the C layer. What caches and stuff do we have on > >> the C layer that can take a significant amount of memory? The image > >> and font caches? Uhm... Anything more? > > > > We have a legion of them. > > That can have significant memory? Some of them could, yes. > I don't think we have to go that far to be useful. Reporting that the > image cache takes foo GB will help somebody. Why would an image cache take that much? we flush it from time to time, and I have difficulty believing that all those users reporting large memory footprints load thousands of images every hour of every day. > > Which variables did you have in mind in this context? Can you show an > > example? > > It'd just traverse all the variables and compute the "largest" ones. Again, they are included in the GC report. So what do you expect to see? > >> And I'd also like to do the same with buffer-local variables, in > >> case a lot of data is hiding there (for instance, the eww-history, > >> which caches old rendered versions of web pages, and may be large). > > > > But those are part of the GC report, aren't they? > > Yes. It's a more detailed look at what's holding on to the memory. But in the cases where people see the memory footprint increasing, the GC report doesn't show any increase in memory use, and the sum total of what it reports is way smaller than several GB. So, while a more detailed report might be nice to have, I don't see how it would help to diagnose "leaks" of the kind we are discussing now on the bug list.