Eli Zaretskii writes: >> From: "Dr. Arne Babenhauserheide" >> 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. That could already help, yes. Maybe not by factor 25 as I did (that’s mostly for lsp work), but just adjusting to how much the lower limit of systems changed that can run Emacs 30. > 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. … > 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. With the main risk being that we could go OOM, could Emacs evaluate the available memory on the system on systems that support that check? If Emacs can give back memory to the OS (I expect that it can, but I am not sure¹), then wrapping the init process into such a check by default could resolve many startup time problems. By reverting to a lower value after startup, it would avoid limiting other processes on the system. ¹: Can Emacs give back memory to the OS? Best wishes, Arne -- Unpolitisch sein heißt politisch sein, ohne es zu merken. draketo.de