emacs-devel
[Top][All Lists]
Advanced

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

Re: Indentation and gc


From: Eli Zaretskii
Subject: Re: Indentation and gc
Date: Sat, 11 Mar 2023 09:56:46 +0200

> From: "Dr. Arne Babenhauserheide" <arne_bab@web.de>
> Cc: spacibba@aol.com, emacs-devel@gnu.org
> Date: Sat, 11 Mar 2023 07:55:32 +0100
> 
> Do we have a process to re-evaluate the current settings? Emacs modes
> have been getting more complex in the past decades — also because modern
> CPUs can execute them — so how can we see whether 800k are still the
> right setting for gc-cons-threshold?

The "right setting" is very much dependent on the setup and resources
on each concrete system.  And people tend to run Emacs on some very
old systems, as well as on some very new ones.  Not sure how to
evaluate the default setting in these circumstances.

Perhaps the only thing we could do is enlarge the value slightly in
Emacs 30.

And please keep in mind that the value of the threshold does NOT
guarantee that Emacs will call GC as soon as it generated Lisp objects
which take that much memory.  The test against the threshold is done
only when Emacs decides it might be a good time to do a GC, so you
could have a Lisp program that runs for prolonged times and generates
much more objects than it takes to reach the threshold, before GC
happens.  It is not very probable to have such programs, but it's
definitely possible.  E.g., a single make-string call can generate a
very large string, which takes much more memory than the threshold,
without calling GC.

So raising the threshold indirectly raises the probability of having
your system run out of memory, even if the threshold value is way
below the amount of VM you have.

> Another question would be whether enlarging the gc cons threshhold
> during reading of the site and init file could be a default. It improves
> startup times a lot.

See above: to what value will you enlarge it so that it's still safe?
The Emacs startup typically does a lot of non-trivial stuff, so could
consume large quantities of memory.



reply via email to

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