From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Tim Connors Newsgroups: gmane.emacs.devel Subject: Re: Memory again Date: Thu, 15 Dec 2011 14:52:23 +1100 (EST) Message-ID: References: <4ED0F945.5090805@yandex.ru> <83pqge7syw.fsf@gnu.org> <87mxb6tkji.fsf@wanadoo.es> <87borlu0kc.fsf@wanadoo.es> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Trace: dough.gmane.org 1323921161 4184 80.91.229.12 (15 Dec 2011 03:52:41 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Thu, 15 Dec 2011 03:52:41 +0000 (UTC) Cc: =?ISO-8859-15?Q?=D3scar_Fuentes?= , emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Dec 15 04:52:37 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 1Rb2N2-0002T8-CT for ged-emacs-devel@m.gmane.org; Thu, 15 Dec 2011 04:52:36 +0100 Original-Received: from localhost ([::1]:35521 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Rb2N1-00088l-Lr for ged-emacs-devel@m.gmane.org; Wed, 14 Dec 2011 22:52:35 -0500 Original-Received: from eggs.gnu.org ([140.186.70.92]:44574) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Rb2Mz-00088R-1r for emacs-devel@gnu.org; Wed, 14 Dec 2011 22:52:33 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Rb2Mx-0004CW-TU for emacs-devel@gnu.org; Wed, 14 Dec 2011 22:52:32 -0500 Original-Received: from ipmail07.adl2.internode.on.net ([150.101.137.131]:26636) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Rb2Mx-0004CI-Js for emacs-devel@gnu.org; Wed, 14 Dec 2011 22:52:31 -0500 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAN5q6U520WSH/2dsb2JhbABEmwiQHoEGgXIBAQQBOhwGHRABCjQSIxYeBogNpj6HWECIeIwHBIpCijOSPg Original-Received: from ppp118-209-100-135.lns20.mel4.internode.on.net (HELO dirac.rather.puzzling.org) ([118.209.100.135]) by ipmail07.adl2.internode.on.net with ESMTP; 15 Dec 2011 14:22:28 +1030 Original-Received: from tconnors (helo=localhost) by dirac.rather.puzzling.org with local-esmtp (Exim 4.72) (envelope-from ) id 1Rb2Mr-000401-4x; Thu, 15 Dec 2011 14:52:26 +1100 In-Reply-To: User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 150.101.137.131 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:146716 Archived-At: On Tue, 6 Dec 2011, Stefan Monnier wrote: > > I'm writing this message on that very same emacs process. Right now it > > has 60 buffers, all of them with a size below 50KB and most below > > 10KB. As reported by `htop', the process is using 533MB of RES memory > > and 630MB of VIRT memory. > > Nothing of what you say sounds worrisome: apparently you now have around > half a GB of memory allocated for use by Lisp data. Most likely the > majority of it is considered by Emacs as "free for reuse", but it's not > returned to the OS because that is only done in "big chunks" (typically > 10KB or so) and none of the big chunks are 100% free (they all contain > at least one non-free object). > Some of that memory may also belong to malloc rather than to Emacs: > Emacs did pass it to `free', but the malloc library decided that it's > not worth returning those elements to the OS. > Of course, it may also be that we have an actual leak (i.e. some of that > memory was neither returned to malloc, nor is it still managed by > Emacs). But as long as you don't have evidence of a leak, I'd suggest > you move on, because there's really not much we can do about the above > problem (short of rewriting the whole memory management to make it > compacting). I recently switched over to Emacs, from XEmacs, porting my .config files over as necessary. I am used to being able to run XEmacs for months on end, with XEmacs's gnuclient, and having hundreds of buffers and dozens of frames open. The XEmacs process would sometimes take 100M or so resident, and if I opened a big file and tried to fontify it, then naturally usage would increase. Some of this would be returned to the OS, some of it wouldn't, when I closed buffers. I lived with that because I didn't tend to stupidly open big files and fontify them too often. But right now, having had emacs up for a few days, and only opening 10 small files with the aid of emacsclient, emacs's RSS is 130M. It had climbed up to 400M before I most recently killed it. What's the differences between emacs's and xemacs's allocators? By the way, the dismissal of this being a real problem because emacs can always reuse the fragmented memory either 1) ignores the fact that computers are general purpose and can run other programs simultaneously (some of them being rather high quality bloatware like mozilla), or 2) takes the view that emacs is an entire operating system, and there's no need to run anything else, a little too seriously -- Tim Connors