Re: Memory usage report

[Eli Zaretskii]

> From: Ihor Radchenko <yantar92@gmail.com>
> Cc: larsi@gnus.org, emacs-devel@gnu.org
> Date: Sat, 19 Sep 2020 23:45:37 +0800
> 
> >> 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?

No, you should be able to tell whether "the resulting speedup worth
extra memory usage".  The memory used by a single overlay can be
easily determined by looking at the contents of an overlay object on
the C level, and similarly with 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.

Call garbage-collect before and after the function, and you can have
that.


> This might even be done in Elisp comparing `cons-cells-consed' and
> similar variables before/after each function call.

Not everything is exposed to Lisp.  For example, how many bytes are
consumed by a cons cell.