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 22:15:24 +0300 Message-ID: <838sd6522b.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> <83pn6j45rr.fsf@gnu.org> <87wo0ri6kz.fsf@gnus.org> <83o8m34433.fsf@gnu.org> <87imcb43e3.fsf@localhost> <83k0wr4222.fsf@gnu.org> <87ft7f40p8.fsf@localhost> <83h7rv3xsc.fsf@gnu.org> <87wo0rdpud.fsf@localhost> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="9769"; mail-complaints-to="usenet@ciao.gmane.io" Cc: larsi@gnus.org, emacs-devel@gnu.org To: Ihor Radchenko Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Fri Sep 18 22:16:52 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 1kJMoN-0002Pn-OH for ged-emacs-devel@m.gmane-mx.org; Fri, 18 Sep 2020 22:16:51 +0200 Original-Received: from localhost ([::1]:37382 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kJMoM-0007my-MN for ged-emacs-devel@m.gmane-mx.org; Fri, 18 Sep 2020 16:16:50 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:56364) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kJLqh-00065k-At for emacs-devel@gnu.org; Fri, 18 Sep 2020 15:15:11 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:55035) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kJLqg-00034r-Mo; Fri, 18 Sep 2020 15:15:10 -0400 Original-Received: from [176.228.60.248] (port=1522 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1kJLqg-0007bm-Ae; Fri, 18 Sep 2020 15:15:10 -0400 In-Reply-To: <87wo0rdpud.fsf@localhost> (message from Ihor Radchenko on Sat, 19 Sep 2020 00:14:34 +0800) 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:256134 Archived-At: > From: Ihor Radchenko > Cc: larsi@gnus.org, emacs-devel@gnu.org > Date: Sat, 19 Sep 2020 00:14:34 +0800 > > Before: > Total in lisp objects: 77.4MB (live 47.7MB, dead 29.7MB) > Buffer ralloc memory usage: > 16 buffers > 39.3kB total (23.6kB in gaps) > > After: > Total in lisp objects: 283MB (live 218MB, dead 64.7MB) > Buffer ralloc memory usage: > 47 buffers > 6.79MB total (78.6kB in gaps) > > This is not all the memory increase. Some part seems to be in heap. I see almost all of the 200MB of additional memory in Lisp objects: mainly conses, the rest in vectors and intervals (i.e. text properties). Where do you see evidence for a significant memory in the heap? I guess you could ask Org developers a question regarding this high memory usage. In any case, this is not what people report in bug#43389, or so it seems. > Also, the memory usage is even worse when org-mode is using overlays (I > am on org-mode branch using text properties instead of overlays in org). Looks like you have 30 Org buffers whose total size is below 10MB? If they use a lot of text properties and overlays, it's a small wonder you get high memory usage. I don't necessarily see a problem here. > The memory consumption gets even worse after I use Emacs for several > hours. Recently, it tend to settle around 20% (of 8Gb) with lisp objects > taking around 1Gb. So the interesting question is: where are those 7GB used? > This last part is the most annoying and also difficult to track - I have > no easy way to know if it is also caused by org-mode or it is something > else. The only way to investigate this is to use a good memory-mapping utility and perhaps also a debugging malloc library. And that is actually the bottom line here: the GBytes of memory used by such large Emacs sessions don't seem to come from Lisp objects, they are used up in some other way. The question is how and where in the code this happens.