Re: Memory usage report

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: emacs-devel@gnu.org
> Date: Fri, 18 Sep 2020 13:47:48 +0200
> 
> >> 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.
> 
> That can have significant memory?

Some of them could, yes.

> I don't think we have to go that far to be useful.  Reporting that the
> image cache takes foo GB will help somebody.

Why would an image cache take that much? we flush it from time to
time, and I have difficulty believing that all those users reporting
large memory footprints load thousands of images every hour of every
day.

> > Which variables did you have in mind in this context?  Can you show an
> > example?
> 
> It'd just traverse all the variables and compute the "largest" ones.

Again, they are included in the GC report.  So what do you expect to
see?

> >> 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?
> 
> Yes.  It's a more detailed look at what's holding on to the memory.

But in the cases where people see the memory footprint increasing, the
GC report doesn't show any increase in memory use, and the sum total
of what it reports is way smaller than several GB.  So, while a more
detailed report might be nice to have, I don't see how it would help
to diagnose "leaks" of the kind we are discussing now on the bug list.