From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: Memory again Date: Tue, 06 Dec 2011 08:29:06 -0500 Message-ID: References: <4ED0F945.5090805@yandex.ru> <83pqge7syw.fsf@gnu.org> <87mxb6tkji.fsf@wanadoo.es> <4EDDED4B.7030607@yandex.ru> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: dough.gmane.org 1323178161 24287 80.91.229.12 (6 Dec 2011 13:29:21 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Tue, 6 Dec 2011 13:29:21 +0000 (UTC) Cc: emacs-devel@gnu.org To: Dmitry Antipov Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Dec 06 14:29:17 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 1RXv5A-0002Vp-5I for ged-emacs-devel@m.gmane.org; Tue, 06 Dec 2011 14:29:16 +0100 Original-Received: from localhost ([::1]:55389 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RXv59-0003ue-Kr for ged-emacs-devel@m.gmane.org; Tue, 06 Dec 2011 08:29:15 -0500 Original-Received: from eggs.gnu.org ([140.186.70.92]:53975) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RXv55-0003tm-Dv for emacs-devel@gnu.org; Tue, 06 Dec 2011 08:29:13 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RXv54-00005x-BS for emacs-devel@gnu.org; Tue, 06 Dec 2011 08:29:11 -0500 Original-Received: from pruche.dit.umontreal.ca ([132.204.246.22]:41795) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RXv54-00005m-6D for emacs-devel@gnu.org; Tue, 06 Dec 2011 08:29:10 -0500 Original-Received: from pastel.home (lechon.iro.umontreal.ca [132.204.27.242]) by pruche.dit.umontreal.ca (8.14.1/8.14.1) with ESMTP id pB6DT6uF021127; Tue, 6 Dec 2011 08:29:07 -0500 Original-Received: by pastel.home (Postfix, from userid 20848) id 287F0593FF; Tue, 6 Dec 2011 08:29:06 -0500 (EST) In-Reply-To: <4EDDED4B.7030607@yandex.ru> (Dmitry Antipov's message of "Tue, 06 Dec 2011 14:24:11 +0400") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.91 (gnu/linux) X-NAI-Spam-Flag: NO X-NAI-Spam-Threshold: 5 X-NAI-Spam-Score: 0 X-NAI-Spam-Rules: 1 Rules triggered RV4062=0 X-NAI-Spam-Version: 2.2.0.9309 : core <4062> : streams <708306> : uri <1022756> X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 132.204.246.22 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:146503 Archived-At: >> I still believe this is what's happening for me on Linux 3.x and >> Darwin 10.7.x when I kill a buffer and the claimed memory is not >> given back to the kernel. > I tried with 1M of #warnings, and (buffer-size *compilation*) was 58M - but > RSS grows to 2250M. During compilation, strace shows an excessive usage both [...] > But even after GC, RSS is 2192M. Oops. While RSS is a useful measure for performance debugging, here it gives us "vague" numbers only since returning 100MB to the kernel may have no effect on the RSS if that memory was not in RAM. Still, the point in any case is that if the buffer is 60MB, then killing it will return those 60MB to the kernel, but it won't return to the kernel the memory allocated for Lisp objects such as interval nodes (used for text-properties), cons cells, strings, etc... So of your 2250MB, only the 60MB of the buffer text will be recovered by the kernel (well, potentially more, depending on how fragmented the Lisp objects are, but in practice these things seems to stick around). The rest will stay property of Emacs. This doesn't mean it's wasted: Emacs should be perfectly able to reuse it next time it needs memory for cons cells, strings, interval nodes, ... E.g. re-running the same compilation should not significantly grow the Emacs process (other than the extra 60MB, of course). Stefan