Re: Indentation and gc

[Eli Zaretskii <eliz@gnu.org>]

> From: Ihor Radchenko <yantar92@posteo.net>
> Cc: arne_bab@web.de, spacibba@aol.com, emacs-devel@gnu.org
> Date: Sat, 11 Mar 2023 13:10:35 +0000
> 
> If so, as you said, there is no guarantee that the threshold is never
> exceeded. So, running Emacs when the available memory is extremely close
> to the heap size is not safe anyway.

What do you mean  by "heap size" here?

We aren't talking about the heap, we are talking about the VM size of
the system, vs how much of that is typically consumed by programs.
The answer depends on the system and on the usage patterns.

> Emacs may start exceeding memory limits just from loading an extra
> package of something along that lines.

It depends how large is the memory consumption of that package and how
much memory the system has.

> Memory-constrained users probably need to carefully search for a balance
> anyway.

The current GC threshold is unlikely to cause problems on systems with
even very little memory.  Emacs itself needs around 15 to 20 MiB even
when started with -Q, so if the system is capable of running Emacs, it
should be able to cope with relatively minor increases of the memory
footprint, such as what the default GC threshold produces.

You suggest increasing the threshold significantly, which could make
the danger of OOM much higher, especially on memory-challenged
systems.

> What about setting gc-cons-threshold (and leaving gc-cons-percentage
> intact) as a fraction of the available memory as returned by
> `memory-info'?

See my other message a few minutes ago, where I already responded to a
similar proposal.

> At least, when loading init.el. This can be a custom
> setting like `gc-cons-threshold-init' that may either be nil (fall back
> to `gc-cons-threshold'), an integer (bytes), or a float representing a
> fraction of free memory. The default can be a fraction of free memory,
> if memory info is available for a given system.

Which fraction?

If we leave determination of the fraction to the user, we might as
well not provide any new defcustoms at all, since the existing
variables cover that, and you are saying that everyone increases the
threshold to most-positive-fixnum anyway.

> I'd introduce a custom setting `gc-cons-percentage-2/`gc-cons-threshold-2'
> that will define an alternative (larger) GC threshold that is used for a
> command if the number of GCs exceeds `gcs-done-threshold'.

How is this different from what we already have?

> Upon finishing the command, GC thresholds are lowered back to standard.

Why only "command"?  What about stuff that runs from post-command-hook
or from timers or from process filters?  Some of them could be as
performance critical as an interactive command, no?

> >   . how to determine the ceiling for increasing the threshold?
> 
> That's a good question.

That's the main question, from my POV.  Without a good answer, we
don't have any reason to introduce any new features related to this.

> I'd start with trying 5-10x normal value of gc-cons-percentage for
> commands that spend more than 0.1-0.2 sec (noticeable delay) in more
> than a single GC.

Again: why only commands?

And how to know which ones will take more that the times you consider
as significant?  (And why should everyone use these times, which
appear to be quite low?)

> Then, I'd add some code that will collect statistics of the impact
> of the new setting. After some time, I will ask users to share the
> statistics in one of the Emacs surveys or just by asking on mailing
> list.

Then we should start with just this, and revisit the issue only after
we have some significant statistics.  Note that users will have to
tell much more than just threshold numbers: they will need to tell how
much memory they have and also the memory footprints of the programs
running on their systems.