[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Emacs bzr memory footprint
From: |
Carsten Mattner |
Subject: |
Re: Emacs bzr memory footprint |
Date: |
Sat, 22 Oct 2011 14:03:38 +0200 |
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.
- Re: Emacs bzr memory footprint, (continued)
- Re: Emacs bzr memory footprint, Nix, 2011/10/21
- Re: Emacs bzr memory footprint, Dmitry Antipov, 2011/10/21
- Re: Emacs bzr memory footprint, Stefan Monnier, 2011/10/21
- Re: Emacs bzr memory footprint, Óscar Fuentes, 2011/10/21
- Re: Emacs bzr memory footprint, Eli Zaretskii, 2011/10/21
- Re: Emacs bzr memory footprint, Nix, 2011/10/21
- Re: Emacs bzr memory footprint, Eli Zaretskii, 2011/10/21
- Re: Emacs bzr memory footprint, Nix, 2011/10/21
- Re: Emacs bzr memory footprint, Carsten Mattner, 2011/10/22
- Re: Emacs bzr memory footprint, Stephen J. Turnbull, 2011/10/22
- Re: Emacs bzr memory footprint,
Carsten Mattner <=
- Re: Emacs bzr memory footprint, Stephen J. Turnbull, 2011/10/22
- Re: Emacs bzr memory footprint, Ted Zlatanov, 2011/10/27
- Re: Emacs bzr memory footprint, Eli Zaretskii, 2011/10/28
- Re: Emacs bzr memory footprint, Stephen J. Turnbull, 2011/10/28
- Re: Emacs bzr memory footprint, Eli Zaretskii, 2011/10/28
- Re: Emacs bzr memory footprint, Stephen J. Turnbull, 2011/10/28
- Re: Emacs bzr memory footprint, Eli Zaretskii, 2011/10/28
- valgrind warnings [Re: Emacs bzr memory footprint], Dan Nicolaescu, 2011/10/28
- valgrind warnings [Re: Emacs bzr memory footprint], Stephen J. Turnbull, 2011/10/28
- Re: valgrind warnings [Re: Emacs bzr memory footprint], Dan Nicolaescu, 2011/10/28