Re: Emacs bzr memory footprint

[Carsten Mattner]

On Sat, Oct 22, 2011 at 10:30 AM, Stephen J. Turnbull
<address@hidden> wrote:
> 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."

Sure.

Actually, if I could port the keybindings which work well with
X or Cocoa Emacs clients to the terminal emulator (-nw), I could
save even more memory.

Any tutorial/gotchas I can study to make my keybindings portable
between xterm, tmux, screen, Cocoa and X (no toolkit)?

The color discrepancy is a minor issue, which can be resolved
with selecting a theme that also looks correct in the term emulator.

> 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!

A GC that doesn't fit the usage patterns may be worse than
no GC at all :). There's a reason we have many GC algos.
Erlang's copying GC fits the many-lightweight processes model
wel, for example. It's hard to use such a GC with the JVM's usual
workloads or GHC's, although GHC has and Erlang process like
the surrounding mechanics and different models included in GHC
make it harder. This is a case where elisp and Erlang have it easier,
I believe.

> 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.

Is the gnutls memory usage a leak, or just some allocated arrays for
crypto arrays? Just a wild guess, nothing scientific to back it up.