Ihor Radchenko writes: > Eli Zaretskii writes: > >>> 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? >> >> It can, but what would you want to do with that value? >> >> We cannot use it as the threshold, for the reasons I explained >> earlier. We could use some fraction of it, but what fraction? The >> answer depends on what other programs routinely run on that system. >> For example, if the user is likely to run another full-fledged session >> of Emacs (some people actually do that, e.g., to run Gnus in a >> separate process), then using 1/2 of the amount of VM as the threshold >> is out of the question, right? And there are memory-hogging programs >> out there which use much more than Emacs does. > > 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. Best wishes, Arne -- Unpolitisch sein heißt politisch sein, ohne es zu merken. draketo.de