From: Ihor Radchenko <yantar92@posteo.net>
To: "Dr. Arne Babenhauserheide" <arne_bab@web.de>
Cc: Eli Zaretskii <eliz@gnu.org>, spacibba@aol.com, emacs-devel@gnu.org
Subject: Re: Indentation and gc
Date: Sun, 12 Mar 2023 13:27:53 +0000 [thread overview]
Message-ID: <877cvmumjq.fsf@localhost> (raw)
In-Reply-To: <87a60jtg0z.fsf@web.de>
"Dr. Arne Babenhauserheide" <arne_bab@web.de> writes:
>> What is the smallest practical free RAM available to Emacs on low-end systems?
>> We can take that value and then use 800kb/min free RAM in the wild and
>> the base threshold. On system with larger RAM the threshold will scale.
>
> It’s not that simple — at least outside loading the init file. If you
> increase this fraction, then GC pauses will be longer and Emacs may feel
> jittery or even become unresponsive for some time.
>
> So there should likely be also a hard upper limit to ensure that the
> pauses are unnoticeable.
Well. I do realize that there should be a limit, which is why I put it
as 100Mb.
Strictly speaking, GC pauses scale with heap size. Increasing GC threshold
will have two effects on the heap size: (1) thresholds lager than normal
heap size will dominate the GC time - Emacs will need to traverse all
the newly added data to be GCed; (2) too large thresholds will cause
heap fragmentation, also increasing the GC times as the heap will expand.
I think that (2) is the most important factor for real world scenarios
(unless we set the threshold insanely high, higher than memory usage in
"heavy" Emacs sessions).
Emacs' default gives some lower safe bound on the threshold - it is
`gc-cons-percentage', defaulting to 1% of the heap size.
However, being safe is unfortunately not enough - apparently 1% heap
size is too less in real world scenarios when 1% is routinely and
frequently allocated, triggering GC rescans too many times.
Especially so, when loading init.el. The heap size is yet smaller than
normal and GC is triggered even more frequently.
AFAIU, routine throw-away memory allocation in Emacs is not directly
correlated with the memory usage - it rather depends on the usage
patterns and the packages being used. For example, it takes about 10
complex helm searches for me to trigger my 250Mb threshold - 25Mb per
helm command. The GC frequency often depends on how heavily I use helm
completion.
To get some idea about the impact of gc-cons-threshold on memory
fragmentation, I compared the output of `memory-limit' with 250Mb vs.
default 800kb threshold:
250Mb threshold - 689520 kb memory
800kb threshold - 531548 kb memory
The memory usage is clearly increased, but not catastrophically, despite
using rather large threshold.
Of course, it is just init.el, which is loaded once. Memory
fragmentation as a result of routine Emacs usage may cause more
significant memory usage increase. Not multiple times though (not even
twice in my setup).
From the above, I expect the increase of gc-cons-threshold 100x to
impact the memory dis-proportionally - between as little as 1.1x and 2x.
As long as gc-cons-threshold is significantly (~10x) lower than normal
Emacs heap size, I expect the GC frequency to scale down the same 100x
at very little cost.
For me, Emacs memory usage typically settles around 1Gb, which is why I
chose 100Mb as an upper limit (1Gb/10).
If we want to be even more safe, as I proposed, we can only increase the
gc-cons-threshold when loading init.el and possibly for certain, most
GC-heavy commands. This will minimize the impact of memory
fragmentation - only a small set of commands (having more regular memory
allocation pattern) will cause the fragmentation.
--
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>
next prev parent reply other threads:[~2023-03-12 13:27 UTC|newest]
Thread overview: 99+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20230310110747.4hytasakomvdyf7i.ref@Ergus>
2023-03-10 11:07 ` Indentation and gc Ergus
2023-03-10 14:36 ` Dr. Arne Babenhauserheide
2023-03-10 14:54 ` Eli Zaretskii
2023-03-10 19:23 ` Dr. Arne Babenhauserheide
2023-03-11 6:38 ` Eli Zaretskii
2023-03-11 6:55 ` Dr. Arne Babenhauserheide
2023-03-11 7:56 ` Eli Zaretskii
2023-03-11 12:34 ` Dr. Arne Babenhauserheide
2023-03-11 13:08 ` Eli Zaretskii
2023-03-11 13:31 ` Ihor Radchenko
2023-03-11 13:44 ` Eli Zaretskii
2023-03-11 13:53 ` Ihor Radchenko
2023-03-11 14:09 ` Eli Zaretskii
2023-03-12 14:20 ` Ihor Radchenko
2023-03-12 14:40 ` Eli Zaretskii
2023-03-12 15:04 ` Ihor Radchenko
2023-03-12 15:26 ` Eli Zaretskii
2023-03-13 15:09 ` Ihor Radchenko
2023-03-13 15:37 ` Eli Zaretskii
2023-03-13 15:45 ` Ihor Radchenko
2023-03-13 16:58 ` Eli Zaretskii
2023-03-13 18:04 ` Ihor Radchenko
2023-03-14 12:19 ` Eli Zaretskii
2023-03-15 10:28 ` Ihor Radchenko
2023-03-15 12:54 ` Eli Zaretskii
2023-03-15 12:59 ` Ihor Radchenko
2023-03-15 14:20 ` Eli Zaretskii
2023-03-16 10:27 ` Ihor Radchenko
2023-04-06 9:13 ` Ihor Radchenko
2023-04-08 8:04 ` Eli Zaretskii
2023-04-08 8:15 ` Ihor Radchenko
2023-04-08 10:03 ` Eli Zaretskii
2023-04-14 17:07 ` Ihor Radchenko
2023-04-14 17:56 ` Eli Zaretskii
2023-03-13 18:14 ` Gregor Zattler
2023-03-14 12:30 ` Eli Zaretskii
2023-03-14 15:19 ` Gregor Zattler
2023-03-11 16:19 ` Dr. Arne Babenhauserheide
2023-03-12 13:27 ` Ihor Radchenko [this message]
2023-03-12 14:10 ` Eli Zaretskii
2023-03-12 14:50 ` Ihor Radchenko
2023-03-12 15:13 ` Eli Zaretskii
2023-03-12 17:15 ` Gregor Zattler
2023-03-12 20:07 ` Eli Zaretskii
2023-03-13 15:01 ` Ihor Radchenko
2023-03-13 15:33 ` Eli Zaretskii
2023-03-13 15:39 ` Ihor Radchenko
2023-03-13 15:39 ` Eli Zaretskii
2023-03-13 16:04 ` Ihor Radchenko
2023-03-13 16:52 ` Eli Zaretskii
2023-03-14 12:47 ` Ihor Radchenko
2023-03-14 13:09 ` Eli Zaretskii
2023-03-15 10:29 ` Ihor Radchenko
2023-03-13 15:41 ` Eli Zaretskii
2023-03-14 13:01 ` Ihor Radchenko
2023-03-11 10:54 ` Ihor Radchenko
2023-03-11 11:17 ` Ergus
2023-03-11 11:23 ` Ihor Radchenko
2023-03-11 12:31 ` Eli Zaretskii
2023-03-11 12:39 ` Ihor Radchenko
2023-03-11 12:40 ` Eli Zaretskii
2023-03-11 12:54 ` Ihor Radchenko
2023-03-11 13:01 ` Dr. Arne Babenhauserheide
2023-03-11 13:14 ` Eli Zaretskii
2023-03-11 13:38 ` Ihor Radchenko
2023-03-11 13:46 ` Eli Zaretskii
2023-03-11 13:54 ` Ihor Radchenko
2023-03-11 14:11 ` Eli Zaretskii
2023-03-11 14:18 ` Ihor Radchenko
2023-03-11 14:20 ` Eli Zaretskii
2023-03-11 14:31 ` Ihor Radchenko
2023-03-11 15:32 ` Eli Zaretskii
2023-03-11 15:52 ` Lynn Winebarger
2023-03-11 16:24 ` Eli Zaretskii
2023-03-11 17:10 ` Gregor Zattler
2023-03-11 17:25 ` Eli Zaretskii
2023-03-11 18:35 ` Gregor Zattler
2023-03-11 18:49 ` Eli Zaretskii
2023-03-13 12:45 ` Ihor Radchenko
2023-03-13 12:51 ` Eli Zaretskii
2023-06-14 14:16 ` Ihor Radchenko
2023-06-14 15:36 ` Eli Zaretskii
2023-06-14 15:58 ` Ihor Radchenko
2023-06-14 16:07 ` Eli Zaretskii
2023-06-16 10:00 ` Ihor Radchenko
2023-06-16 10:33 ` Eli Zaretskii
2023-06-16 11:03 ` Ihor Radchenko
2023-06-16 11:34 ` Eli Zaretskii
2023-06-21 10:37 ` Ihor Radchenko
2023-06-21 11:11 ` Eli Zaretskii
2023-03-11 13:00 ` Po Lu
2023-03-11 12:37 ` Eli Zaretskii
2023-03-11 13:10 ` Ihor Radchenko
2023-03-11 13:38 ` Eli Zaretskii
2023-03-10 14:52 ` Eli Zaretskii
2023-03-10 21:30 ` Ergus
2023-03-11 6:52 ` Eli Zaretskii
2023-03-21 7:11 ` Jean Louis
2023-03-21 7:27 ` Emanuel Berg
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=877cvmumjq.fsf@localhost \
--to=yantar92@posteo.net \
--cc=arne_bab@web.de \
--cc=eliz@gnu.org \
--cc=emacs-devel@gnu.org \
--cc=spacibba@aol.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.