Re: Indentation and gc

[Ihor Radchenko]

Eli Zaretskii <eliz@gnu.org> writes:

>> I meant that as long as gc-cons-threshold is much lower (10x or so) than
>> heap size (Lisp object part), we do not need to worry about (1). Only
>> (2) remains a concern.
>
> Your gc-cons-threshold is 250 MiB.  If it's below 0.1 of the size of
> Lisp data, does that mean you 2.5 GiB or more of Lisp data in your
> sessions?  That's a lot.  I have less than 300 MiB, for comparison,
> and this is a session that runs for 25 days non-stop, and has a
> 520 MiB memory footprint.

I said nothing about my settings. Because my settings are tailored to my
usage.

In this discussion, I am trying to deduce something reasonable based on
logic, not just on what works for me personally.

>> 10% also means that 800k gc-cons-threshold does not matter much even
>> with emacs -Q -- it uses over 8Mb memory and thus gc-cons-percentage
>> should dominate the GC, AFAIU.
>
> How did you measure those 8Mb?  On my system, memory-report in
> "emacs -Q" shows less than 2 MiB in object memory.

emacs -Q M-x memory-report on my side gives

Estimated Emacs Memory Usage

   3.2 MiB  Overall Object Memory Usage
   2.2 MiB  Memory Used By Global Variables
   1.3 MiB  Memory Used By Symbol Plists
   334 KiB  Reserved (But Unused) Object Memory
    66 KiB  Total Image Cache Size
    21 KiB  Total Buffer Memory Usage

A sum of all the above is 7.121, which I rounded up.

>> Note that my proposed 100Mb gc-cons-threshold limit will correspond to
>> 1Gb live Lisp objects. For reference, this is what I have now (I got the
>> data using memory-usage package):
>> 
>>    Total in lisp objects: 1.33GB (live 1.18GB, dead  157MB)
>
> We need to align and calibrate our measurement means: what does
> memory-report tell about object memory in that session?  1.18 GiB
> sounds a lot.

Unfortunately, memory-report is not usable in my sessions. M-x
memory-report takes 10+ minutes and then fails with max nesting error
for me. That's why I use memory-usage third-party package, which
produces some info and does it in reasonable time.

>> > Actually, Emacs tries very hard to avoid fragmentation.  That's why it
>> > compacts buffers, and that's why it can relocate buffer text and
>> > string data.
>> 
>> Indeed. But despite all of the best efforts, fragmentation increases if
>> we delay GCs, right?
>
> Not IME, no.  That's why the memory footprint of a typical
> long-running session levels out.

Then what is the mechanism of gc-cons-threshold affecting the Emacs
memory footprint?

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>