Re: Indentation and gc

[Eli Zaretskii]

> From: Gregor Zattler <telegraph@gmx.net>
> Cc: spacibba@aol.com, arne_bab@web.de, emacs-devel@gnu.org
> Date: Sat, 11 Mar 2023 18:10:33 +0100
> 
> > Again, you are reasoning about the value as if it were related to the
> > maximum memory footprint Emacs could have.  But in fact, it is related
> > only to the _increment_ of memory Emacs can have before it should stop
> > and consider how much of that is garbage.
> 
> But isn't that the very reason, why Ihors gc-cons-threshold
> calculation in mid:878rg3wh2f.fsf@localhost is on the
> save side memory wise?  Because it's a fraction of emacs
> overall memory consumption anyway but scaled regarding
> the total amount of memory?

No.  The limitation on the _increment_ should have nothing to do with
how much memory is already consumed or how much total memory is
available on the system.  Imagine an Emacs with N MiB of memory
footprint on a system that has N+1 MiB of memory available.

IOW, what matters is how much is _left_, not how much is already used
or totally available.

> To me the problem with big gc-cons-threshold even on systems
> which are even bigger on RAM is that the (rare) garbage
> collection the takes much more time and an uneducated
> user might think Emacs hangs.

That is another downside of large GC threshold, yes.  Which again
tells us that making the threshold grow linearly with the available
total VM is not TRT, there should be a hard limit that is not just
arbitrary, but related to the time it takes to perform GC on that many
objects.

> I played a lot recently witch gc-cons-threshold settings due
> to Emacs being too sluggish with my old ones.  Now I:
> 
> - set gc-cons-threshold very high at the beginning of
>   startup  (* 4096 40960)
> - set it lower at the end of startup
>   (/ (* 4096 4096) 1)
>   - use gcmh with this value
> - set it very high when entering the mini-buffer and
>   lower again when exiting it
> - force a gc when frame loses focs
> 
> The result is that with emacs-uptime being 7 hours, 21
> minutes (and plenty of time away from the computer) I
> have 103 messages regarding Garbage collection with
> accompanied times for them in my message buffer.
> 
> Some statistics:
> 
> Minimal number        0.000   seconds
> Maximal number        2.603   seconds
> Sum   65.896  seconds
> Average       0.63976699029126213592  seconds
> Median        0.612   seconds
> Variance      0.06970711075501932322
> Standard deviation    0.26402104225803541665
> 
> Actually 0.6 seconds are already rather long I think.
> But it's much better than before (on a ca. 9 years old
> x240 with 8GB RAM)

The above means you tuned the threshold to your system and personal
needs.  Which is what everyone should do if they are bothered by
frequent GC cycles and too long run times of some Lisp programs they
care about.

> Therefore I think some auto-adjustment of
> gc-cons-threshold would be nice, which would try to
> optimize for low number of garbage collection and short
> times of actual gc runs.

"Therefore"? how does this follow from what you did?  Your tuning is
static and is appropriate for your usage.  Others will most probably
come up with different numbers using the same procedure.  How do you
propose to make this into some kind of auto-adjustment, when how much
garbage is generated and the amount of slowdown this incurs depends on
the Lisp programs that typically run?