[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Memory usage report

From: Eli Zaretskii
Subject: Re: Memory usage report
Date: Sat, 19 Sep 2020 10:51:33 +0300

> From: Ihor Radchenko <yantar92@gmail.com>
> 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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]