emacs-devel
[Top][All Lists]
Advanced

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

Re: Indentation and gc


From: Ihor Radchenko
Subject: Re: Indentation and gc
Date: Sat, 11 Mar 2023 13:10:35 +0000

Eli Zaretskii <eliz@gnu.org> writes:

>> > This can only be done around specific portions of code known in
>> > advance to be long and GC-intensive.  I don't think this kind of
>> > technique can be used in the situation described by the OP.
>> 
>> May it be done when loading init.el and early-init.el?
>
> See my response, where I explain that it is not easy, AFAIU.

Are you referring to
83fsabyb41.fsf@gnu.org">https://yhetil.org/emacs-devel/83fsabyb41.fsf@gnu.org ?

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. Emacs may start exceeding memory
limits just from loading an extra package of something along that lines.
Memory-constrained users probably need to carefully search for a balance
anyway.

What about setting gc-cons-threshold (and leaving gc-cons-percentage
intact) as a fraction of the available memory as returned by
`memory-info'? 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. The default may even
disable this whole thing when the available system memory is small.

>> As for "known in advance", may Emacs keep track of how many GCs are
>> triggered by user commands and then adjust GC dynamically?
>
> Adjust how?  If you mean enlarge under some conditions, then please
> tell:
>
>   . what are those conditions?

AFAIR, being too smart here does not work well. I experimented with
similar ideas in the past (by modifying gcmh package).

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

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

>   . should the threshold also go down under some other conditions, and
>     if so, how?

I do not think that the threshold should be lowered. This increased
value should not affect many commands to start with - just the most
resource-intensive ones.

>   . how to determine the ceiling for increasing the threshold?

That's a good question.
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. 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.

Of course, the experiment should happen on master. Not on the release branch.
Maybe with extra statistics collected after the release in Emacs survey.

I tried something similar in Org. See
https://list.orgmode.org/m2y1p22nfn.fsf@ioa48nv.localdomain/T/#t

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



reply via email to

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