Eli Zaretskii writes: >> From: "Dr. Arne Babenhauserheide" >> Cc: spacibba@aol.com, emacs-devel@gnu.org >> Date: Fri, 10 Mar 2023 20:23:18 +0100 >> >> > 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. >> >> This is at the end: My emacs simply has a ~25x higher gc threshold than >> normal and allows more caching of process output. >> >> That helps a lot with lsp (language servers). > > The enlarged threshold should be carefully tuned to the user's Emacs > usage patterns and to the amount of available virtual memory, to avoid > applying too much memory pressure on the system, which could > potentially lead to OOM killer doing its gruesome job. > > So, instead of advising random users to raise the GC threshold to > levels that are (perhaps) suitable for your configuration and usage > patterns, we should IMO teach them how to tune the threshold to > theirs, and leave the setting to them. That’s true … 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? 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. Best wishes, Arne -- Unpolitisch sein heißt politisch sein, ohne es zu merken. draketo.de