[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Memory usage report

From: Lars Ingebrigtsen
Subject: Re: Memory usage report
Date: Fri, 18 Sep 2020 13:47:48 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux)

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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]