Eli Zaretskii writes: >> Session statistics is much harder to gather. >> It is more realistic to ask people about benchmarking their init.el if >> we want to be serious about bumping gc-cons-threshold. > > We should ask them to report statistics after running a session for > enough time. What exactly qualifies as "enough time" depends on the > usage patterns: there are people, like me, who run a single session > for weeks on end, and there are others who start a new session every > day or even more frequently. What is interesting is the statistics > near the end of the session. > > Statistics from loading init.el is much less interesting, mainly > because reducing GC impact during such short intervals is easy and > well-understood. We could collect such statistics as well, but it is > not the main goal from where I stand. I think we can ask interested users to install a package like https://git.sr.ht/~yantar92/emacs-gc-stats/tree/main/item/emacs-gc-stats.el Then, they can share the results after running Emacs with the package for some time. See the attached statistics data example. WDYT? >> That's why I am seeing reducing the frequency of GCs as more important >> than trying to reduce GC time, which cannot be even halved easily. > > A single very long GC will be annoying even if it happens rarely. So > I don't agree the frequency of GCs is so much more important than the > time it takes to perform a GC. I do not really mean that it is not important. But there is little Emacs can do about the memory consumption. It mainly depends on the third-party packages being used. In contrast, GC frequency is something that can be tweaked easily on Emacs side by altering GC thresholds. >> >> - memory-limit 6,518,516, stable >> > >> > ??? That's 6 GiB. Didn't you say your memory footprint stabilizes at >> > 1 GiB? >> >> memory-limit is a natively compiled function defined in subr.el. > > If the Emacs memory usage in system monitor is 1.7 Gib, how come > memory-limit says it's 6.5 GiB? 6.5Gib is virtual memory. 1.7Gib is actually used memory - the value people usually mean when considering memory footprint.