Re: Memory usage report

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

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

It's negative evidence, but that's useful, too, sometimes.

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

> 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 don't think we have to go that far to be useful.  Reporting that the
image cache takes foo GB will help somebody.

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

It'd just traverse all the variables and compute the "largest" ones.

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

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no