From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Emacs bzr memory footprint Date: Thu, 13 Oct 2011 12:01:41 +0200 Message-ID: <83fwix2osa.fsf@gnu.org> References: Reply-To: Eli Zaretskii NNTP-Posting-Host: lo.gmane.org X-Trace: dough.gmane.org 1318500222 20248 80.91.229.12 (13 Oct 2011 10:03:42 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Thu, 13 Oct 2011 10:03:42 +0000 (UTC) Cc: emacs-devel@gnu.org To: Carsten Mattner Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Oct 13 12:03: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 1REI8W-0005RJ-9X for ged-emacs-devel@m.gmane.org; Thu, 13 Oct 2011 12:03:36 +0200 Original-Received: from localhost ([::1]:57061 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1REI8V-0002uW-Ih for ged-emacs-devel@m.gmane.org; Thu, 13 Oct 2011 06:03:35 -0400 Original-Received: from eggs.gnu.org ([140.186.70.92]:36208) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1REI8S-0002uM-T1 for emacs-devel@gnu.org; Thu, 13 Oct 2011 06:03:33 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1REI8R-0005u3-CF for emacs-devel@gnu.org; Thu, 13 Oct 2011 06:03:32 -0400 Original-Received: from mtaout22.012.net.il ([80.179.55.172]:64030) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1REI8R-0005to-5q for emacs-devel@gnu.org; Thu, 13 Oct 2011 06:03:31 -0400 Original-Received: from conversion-daemon.a-mtaout22.012.net.il by a-mtaout22.012.net.il (HyperSendmail v2007.08) id <0LT000E0013XEH00@a-mtaout22.012.net.il> for emacs-devel@gnu.org; Thu, 13 Oct 2011 12:01:43 +0200 (IST) Original-Received: from HOME-C4E4A596F7 ([84.229.17.178]) by a-mtaout22.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0LT000D8916QOXC0@a-mtaout22.012.net.il>; Thu, 13 Oct 2011 12:01:40 +0200 (IST) In-reply-to: X-012-Sender: halo1@inter.net.il X-detected-operating-system: by eggs.gnu.org: Solaris 10 (beta) X-Received-From: 80.179.55.172 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:145112 Archived-At: > Date: Thu, 13 Oct 2011 11:24:25 +0200 > From: Carsten Mattner > > I've been wondering whether it's normal for Emacs to start with > 10 or 20 megs and stay at ~100 megs after opening and closing > multiple buffers. It depends on what you mean by "opening and closing". My Emacs session is running for 19 hours and its current footprint is 187MB, but it has 273 buffers of various sizes. This is on a 32-bit machine. So please show a minimal sequence of commands that bring you from 20MB up to 100MB. Please also tell what platform is this on (64-bit hosts are expected to use more memory than 32-bit hosts). > Does Emacs have some kind of memory reclaim or gc mechanism? Of course, Emacs includes garbage collector. It runs automatically, but you can also invoke it manually with "M-x garbage-collect RET". > Speaking about memory, I've always wondered why mmap is listed > as not enabled by configure. I think mmap is always used if available and workable. The configure script includes a test for it, it announces itself as "checking for working mmap". Does this test fail for you? If so, look in config.log for the reasons.