Re: Memory usage report

[Eli Zaretskii <eliz@gnu.org>]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: emacs-devel@gnu.org
> Date: Fri, 18 Sep 2020 12:51:52 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > Not that I'd object to formatting this in better ways (especially
> > since a package to do that is already on ELPA), but from experience,
> > memory related problems are very rarely in GC-related areas.  So for
> > diagnosing memory leaks, the GC report is not very useful.
> 
> Even in the presence of a C-level genuine leak, it's useful -- because
> it shows you that the memory is indeed not taken by Lisp-level objects.

Yes, but that's a negative evidence, so it doesn't give any hints
regarding where to look for the problem.

> But for this command to be useful in general, I think we'll have to
> expose more data from the C layer.  What caches and stuff do we have on
> the C layer that can take a significant amount of memory?  The image
> and font caches?  Uhm...  Anything more?

We have a legion of them.

The problem with reporting that memory is that we'd need to monitor
calls that free memory as well, and "forget" the chunks that have been
freed.  At which point we will probably realize that there are
memory-debugging libraries out there, and it's probably easier to
build Emacs with one of them instead of rolling out our own.

> I'd also like the display to list, say, the ten "largest variables".

Which variables did you have in mind in this context?  Can you show an
example?

> And I'd also like to do the same with buffer-local variables, in
> case a lot of data is hiding there (for instance, the eww-history,
> which caches old rendered versions of web pages, and may be large).

But those are part of the GC report, aren't they?