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 14:42:16 +0300 Message-ID: <83r1qz48h3.fsf@gnu.org> References: <87lfh8kyot.fsf@gnus.org> <83k0ws5hzt.fsf@gnu.org> <87h7rwkxtk.fsf@gnus.org> <83imcb61p7.fsf@gnu.org> <871rizl5mf.fsf@gnus.org> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="31447"; 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 13:43:18 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 1kJEnN-00084o-6d for ged-emacs-devel@m.gmane-mx.org; Fri, 18 Sep 2020 13:43:17 +0200 Original-Received: from localhost ([::1]:34990 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kJEnM-00060g-8J for ged-emacs-devel@m.gmane-mx.org; Fri, 18 Sep 2020 07:43:16 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:48888) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kJEmC-0005By-0x for emacs-devel@gnu.org; Fri, 18 Sep 2020 07:42:04 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:41916) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kJEmB-0005DK-NF; Fri, 18 Sep 2020 07:42:03 -0400 Original-Received: from [176.228.60.248] (port=1559 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1kJEmA-00068O-Rw; Fri, 18 Sep 2020 07:42:03 -0400 In-Reply-To: <871rizl5mf.fsf@gnus.org> (message from Lars Ingebrigtsen on Fri, 18 Sep 2020 12:51:52 +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:256075 Archived-At: > From: Lars Ingebrigtsen > Cc: emacs-devel@gnu.org > Date: Fri, 18 Sep 2020 12:51:52 +0200 > > Eli Zaretskii writes: > > > Not that I'd object to formatting this in better ways (especially > > since a package to do that is already on ELPA), but from experience, > > memory related problems are very rarely in GC-related areas. So for > > diagnosing memory leaks, the GC report is not very useful. > > Even in the presence of a C-level genuine leak, it's useful -- because > it shows you that the memory is indeed not taken by Lisp-level objects. Yes, but that's a negative evidence, so it doesn't give any hints regarding where to look for the problem. > 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. The problem with reporting that memory is that we'd need to monitor calls that free memory as well, and "forget" the chunks that have been freed. At which point we will probably realize that there are memory-debugging libraries out there, and it's probably easier to build Emacs with one of them instead of rolling out our own. > I'd also like the display to list, say, the ten "largest variables". Which variables did you have in mind in this context? Can you show an example? > 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?