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: Sat, 19 Sep 2020 10:51:33 +0300 Message-ID: <83wo0q2ohm.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> <838sd6522b.fsf@gnu.org> <87tuvuehhq.fsf@localhost> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="27065"; 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 Sat Sep 19 09:52:06 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 1kJXfC-0006vo-0l for ged-emacs-devel@m.gmane-mx.org; Sat, 19 Sep 2020 09:52:06 +0200 Original-Received: from localhost ([::1]:41308 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kJXfB-0002td-2P for ged-emacs-devel@m.gmane-mx.org; Sat, 19 Sep 2020 03:52:05 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:56448) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kJXeR-0002Tk-RR for emacs-devel@gnu.org; Sat, 19 Sep 2020 03:51:19 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:41185) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kJXeR-0001Sq-F6; Sat, 19 Sep 2020 03:51:19 -0400 Original-Received: from [176.228.60.248] (port=3888 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1kJXeQ-0000f4-Jg; Sat, 19 Sep 2020 03:51:19 -0400 In-Reply-To: <87tuvuehhq.fsf@localhost> (message from Ihor Radchenko on Sat, 19 Sep 2020 08:29:37 +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:256149 Archived-At: > From: Ihor Radchenko > Cc: larsi@gnus.org, emacs-devel@gnu.org > Date: Sat, 19 Sep 2020 08:29:37 +0800 > > > Where do you see evidence for a significant memory in > > the heap? > > top shows more than 200Mb memory increase. Which are explained by the statistics produced by GC. IOW, you have many more live Lisp objects, which take up those megabytes. > While I would also like to answer this question, I also have large > fraction of lisp objects. As I mentioned in previous emails (sorry if I > was not clear), I would appreciate some way to understand why my **lisp > object** memory grew from 283Mb right after loading my org files to 1Gb > later. Since that's related to Org buffers, the best place to discuss this is on Org mailing lists. Perhaps there are ways to make Org use less memory, but the expertise for that is there. Producing memory usage for buffer-local variables will AFAIU need support on the C level, so if someone wants to work on that, please do. However, issues like this one are very infrequent in Emacs maintenance; most of the memory-related problems are not due to some package using up many Lisp objects. > I tried to use memory profiler to understand the memory usage, but the > memory profiler report appear to show peak memory usage (there tend to > be functions with many let-bindings). So, it seems not be to useful for > me (correct me if I am wrong). The "memory" profiler doesn't measure the usage of memory, it measures CPU usage triggered by memory allocation calls (instead of the periodic profiling signal). So this profile is not supposed to be useful for profiling memory usage.