Re: Memory usage report

[Ihor Radchenko <yantar92@gmail.com>]

>> Some of the overlays and text properties are not strictly necessary.
>> For example, text properties are sometimes used as cache to avoid
>> parsing text multiple times. Is the resulting speedup worth extra memory
>> usage? It is not clear since we do not have an easy way to determine the
>> extra memory usage. 
>
> These are exactly the questions to ask the Org developers, I think.

As an org developer, how can I know the extra memory usage by that one
specific type of text properties?

> What that profiler counts is calls to memory-allocation functions,
> that's all.  Without being able to account for memory which was freed
> after being allocated, these counts are useless.

Got it. Then, I imagine that a simple delta of before/after running a
function could be used to build a more useful memory report. Current GC
report only provides the total usage, but no information on how
individual function calls increased the memory usage. This might even be
done in Elisp comparing `cons-cells-consed' and similar variables
before/after each function call.

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 23:14:52 +0800
>> 
>> > I think the more useful question is: are all those overlays and text
>> > properties necessary?  If they are, they take the memory they are
>> > supposed to take.
>> 
>> Some of the overlays and text properties are not strictly necessary.
>> For example, text properties are sometimes used as cache to avoid
>> parsing text multiple times. Is the resulting speedup worth extra memory
>> usage? It is not clear since we do not have an easy way to determine the
>> extra memory usage. 
>
> These are exactly the questions to ask the Org developers, I think.
>
>> > If you mean memory used by non-Lisp objects, I don't see how we could
>> > produce that without having infrastructure for tracking memory
>> > allocation, something that debugging malloc libraries already do.
>> 
>> Hmm. I am looking again at the profiler-report output. It seems to
>> report the memory allocation for individual function calls (that's what
>> I meant by "real" memory profiler). Do I miss something?
>
> What that profiler counts is calls to memory-allocation functions,
> that's all.  Without being able to account for memory which was freed
> after being allocated, these counts are useless.