From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Carsten Mattner Newsgroups: gmane.emacs.devel Subject: Re: Emacs bzr memory footprint Date: Sat, 22 Oct 2011 14:03:38 +0200 Message-ID: References: <83fwix2osa.fsf@gnu.org> <0B3EE7A4-D0D6-4D1E-ADC4-0BEE68F179B2@mit.edu> <87fwivwp37.fsf@turtle.gmx.de> <87sjmvpmd2.fsf@lifelogs.com> <87aa93wmc4.fsf@turtle.gmx.de> <87sjmnrdjw.fsf@spindle.srvr.nix> <87ty73mc0m.fsf@spindle.srvr.nix> <4EA19111.7060401@yandex.ru> <87vcrhfmww.fsf@uwakimon.sk.tsukuba.ac.jp> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Trace: dough.gmane.org 1319285031 25492 80.91.229.12 (22 Oct 2011 12:03:51 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Sat, 22 Oct 2011 12:03:51 +0000 (UTC) Cc: Dmitry Antipov , Stefan Monnier , emacs-devel@gnu.org To: "Stephen J. Turnbull" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Oct 22 14:03:46 2011 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([140.186.70.17]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1RHaIj-0003QF-Vz for ged-emacs-devel@m.gmane.org; Sat, 22 Oct 2011 14:03:46 +0200 Original-Received: from localhost ([::1]:37613 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RHaIj-00006X-HU for ged-emacs-devel@m.gmane.org; Sat, 22 Oct 2011 08:03:45 -0400 Original-Received: from eggs.gnu.org ([140.186.70.92]:55449) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RHaIg-000063-14 for emacs-devel@gnu.org; Sat, 22 Oct 2011 08:03:43 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RHaIe-0004cR-Fs for emacs-devel@gnu.org; Sat, 22 Oct 2011 08:03:41 -0400 Original-Received: from mail-ey0-f169.google.com ([209.85.215.169]:40774) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RHaIe-0004cG-69 for emacs-devel@gnu.org; Sat, 22 Oct 2011 08:03:40 -0400 Original-Received: by eye4 with SMTP id 4so5207902eye.0 for ; Sat, 22 Oct 2011 05:03:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=gCoWOS/X+qk/lQL4pV/zHXOiVVuNxZm2E1b4VCP1cB8=; b=V352Y9CvF5IaSt2o+Ek9J25AQrFEjERtxoOE1Aa0nF4duJfIqx+GEFoMTAgKEJBN0P A0x/GIhCuDni6tYMENH3qtrJB1vm7PMPDwKJtO4a/7p95cOYhTFoMNUrzMYKAsYKK7YO iVs+0ktDl8ciZWMW8gqkjGveyZrjEkP1F3MU4= Original-Received: by 10.223.81.196 with SMTP id y4mr31089118fak.6.1319285018955; Sat, 22 Oct 2011 05:03:38 -0700 (PDT) Original-Received: by 10.152.37.8 with HTTP; Sat, 22 Oct 2011 05:03:38 -0700 (PDT) In-Reply-To: <87vcrhfmww.fsf@uwakimon.sk.tsukuba.ac.jp> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 2) X-Received-From: 209.85.215.169 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:145419 Archived-At: On Sat, Oct 22, 2011 at 10:30 AM, Stephen J. Turnbull 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. =A0In those applications, freeing memory after > use helps a lot. =A0Emacs 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. =A0If that's more memory than you can afford, there's little we > can do. =A0Probably 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? =A0While 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.