[Top][All Lists]

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

Re: Memory usage report

From: Eli Zaretskii
Subject: Re: Memory usage report
Date: Sat, 19 Sep 2020 17:53:21 +0300

> From: Ihor Radchenko <yantar92@gmail.com>
> Cc: larsi@gnus.org, emacs-devel@gnu.org
> Date: Sat, 19 Sep 2020 22:34:28 +0800
> >> top shows more than 200Mb memory increase.
> >
> > Which are explained by the statistics produced by GC.  IOW, you have
> > many more live Lisp objects, which take up those megabytes.
> I meant that 200Mb is Lisp objects, but top shows more then 200Mb
> (around 300Mb). So, there is extra 100Mb coming from somewhere else.

I got a different (smaller) value, but it isn't worth to continue this

> > Since that's related to Org buffers, the best place to discuss this is
> > on Org mailing lists.  Perhaps there are ways to make Org use less
> > memory, but the expertise for that is there.
> The problem is how to identify where the memory usage is coming from.
> Indeed, org is using overlays and text properties extensively. But how
> much do those influence the memory usage?

I think the more useful question is: are all those overlays and text
properties necessary?  If they are, they take the memory they are
supposed to take.

> > The "memory" profiler doesn't measure the usage of memory, it measures
> > CPU usage triggered by memory allocation calls (instead of the
> > periodic profiling signal).  So this profile is not supposed to be
> > useful for profiling memory usage.
> Thanks! I did not know that. Would it be possible to have a "real"
> memory profiler showing how much the memory usage changed after-before
> running separate functions?

If you mean memory used by Lisp objects, then GC reports that.

If you mean memory used by non-Lisp objects, I don't see how we could
produce that without having infrastructure for tracking memory
allocation, something that debugging malloc libraries already do.

reply via email to

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