Re: Indentation and gc

[Gregor Zattler <telegraph@gmx.net>]

Hi Eli, emacs developers,
* Eli Zaretskii <eliz@gnu.org> [2023-03-11; 19:25 +02]:
>> 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

>> 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.

At the moment Emacs does not adjust gc-cons-threshold
to how much memory is left but uses a static
gc-cons-threshold which is rather low.  Ihor's
calculations use the same conservative rather low value
but scales it with overall memory.

[...]
> 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?

I did it statically because I lack the ability to
program an auto-adjusting solution.

But it would be nice if gc-cons-threshold would be
adjusted after each garbage collection in relation to
the amount of time consumed in the last garbage
collections.

I envision an over-engineered customizable variable
called gc-time-service-level-agreement which would
feature two values: one for the maximum of time in
seconds allowed to spend in garbage collection and
another for the percentage of cases where this promise
of maximum time for garbage collection must be kept.
Default: (0.5 . 80)

Or some such.  This wished for auto-adjustment of
garbage collection would help cater to the needs of
users of different packages and major modes.

Ciao; Gregor