Re: Memory usage report

[Ihor Radchenko <yantar92@gmail.com>]

>> 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.

I meant that 200Mb is Lisp objects, but top shows more then 200Mb
(around 300Mb). So, there is extra 100Mb coming from somewhere else.

> 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.

The problem is how to identify where the memory usage is coming from.
Indeed, org is using overlays and text properties extensively. But how
much do those influence the memory usage? I am somewhat familiar with
org-mode codebase, but I have no idea how to debug memory usage issues
on practice. Total memory usage report provides little clue about what
should be changed.

> 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.

Thanks! I did not know that. Would it be possible to have a "real"
memory profiler showing how much the memory usage changed after-before
running separate functions? This could help debugging memory usage (i.e.
in org-mode).

Best,
Ihor

Eli Zaretskii <eliz@gnu.org> writes:

>> 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.