From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Stephen J. Turnbull" Newsgroups: gmane.emacs.devel Subject: Re: Emacs bzr memory footprint Date: Sat, 22 Oct 2011 17:30:55 +0900 Message-ID: <87vcrhfmww.fsf@uwakimon.sk.tsukuba.ac.jp> 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> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 X-Trace: dough.gmane.org 1319272275 17915 80.91.229.12 (22 Oct 2011 08:31:15 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Sat, 22 Oct 2011 08:31:15 +0000 (UTC) Cc: Dmitry Antipov , Stefan Monnier , emacs-devel@gnu.org To: Carsten Mattner Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Oct 22 10:31:11 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 1RHWyz-0006Ld-EG for ged-emacs-devel@m.gmane.org; Sat, 22 Oct 2011 10:31:09 +0200 Original-Received: from localhost ([::1]:40193 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RHWyy-0002bt-6K for ged-emacs-devel@m.gmane.org; Sat, 22 Oct 2011 04:31:08 -0400 Original-Received: from eggs.gnu.org ([140.186.70.92]:37592) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RHWyv-0002bd-Sk for emacs-devel@gnu.org; Sat, 22 Oct 2011 04:31:07 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RHWyu-0000U8-KT for emacs-devel@gnu.org; Sat, 22 Oct 2011 04:31:05 -0400 Original-Received: from mgmt1.sk.tsukuba.ac.jp ([130.158.97.223]:39111) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RHWyu-0000TJ-4g for emacs-devel@gnu.org; Sat, 22 Oct 2011 04:31:04 -0400 Original-Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) by mgmt1.sk.tsukuba.ac.jp (Postfix) with ESMTP id A599A3FA0576; Sat, 22 Oct 2011 17:30:55 +0900 (JST) Original-Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id 9BF601A2888; Sat, 22 Oct 2011 17:30:55 +0900 (JST) In-Reply-To: X-Mailer: VM 8.2.0a1 under 21.5 (beta31) "ginger" 76fad4a87f68 XEmacs Lucid (x86_64-unknown-linux) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-Received-From: 130.158.97.223 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:145415 Archived-At: Carsten Mattner writes: > On Fri, Oct 21, 2011 at 8:00 PM, Stefan Monnier > 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.