Re: Emacs bzr memory footprint

[Stephen J. Turnbull]

Carsten Mattner writes:
 > On Fri, Oct 21, 2011 at 8:00 PM, Stefan Monnier
 > <address@hidden> wrote:

 > > While this is not perfect, I don't consider it to be a serious problem.
 > > E.g. when people complain about Emacs using a lot of memory it's always
 > > (until now and I think in Nix's case as well) a case of too much memory
 > > being used because of something like a leak, and not just "Emacs doesn't
 > > return its free memory to the OS".
 > 
 > It is a problem for everybody like me who doesn't have
 > gigs of free RAM. Sorry.

Nobody is saying that running out of memory isn't a serious problem.
Stefan's point is simply that "if you don't have enough RAM to use
Emacs comfortably, you don't have enough RAM to use Emacs comfortably."

There are applications that use huge amounts of memory at
initialization or in the early part of an algorithm, then can free it
and never need it again.  In those applications, freeing memory after
use helps a lot.  Emacs isn't one of those; average memory usage is
normally a reasonably high fraction of peak usage (at least 75%, often
effectively 100%, in my own usage patterns) and the peaks tend to
recur.  If that's more memory than you can afford, there's little we
can do.  Probably memory usage can be decreased on average or even at
peak by a few percent, but is it worth the effort to develop and
maintain very sophisticated allocators?  While it is my belief that
XEmacs's current excess memory consumption is related to system
libraries like X, I have to admit that reports started to appear about
the same time that a new garbage collection framework was introduced
-- it's quite possible that the new GC is buggy!

On the other hand, memory leaks of various kinds are bugs that should
be fixed when understood, and in the meantime features that trigger
them identified so you can avoid them.