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: Memory again Date: Tue, 06 Dec 2011 19:20:09 +0200 Message-ID: <8362htbos6.fsf@gnu.org> References: <4ED0F945.5090805@yandex.ru> <83pqge7syw.fsf@gnu.org> <87mxb6tkji.fsf@wanadoo.es> <4EDDED4B.7030607@yandex.ru> Reply-To: Eli Zaretskii NNTP-Posting-Host: lo.gmane.org X-Trace: dough.gmane.org 1323192084 19702 80.91.229.12 (6 Dec 2011 17:21:24 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Tue, 6 Dec 2011 17:21:24 +0000 (UTC) Cc: dmantipov@yandex.ru, emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Dec 06 18:21:20 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 1RXyhh-0006q2-RZ for ged-emacs-devel@m.gmane.org; Tue, 06 Dec 2011 18:21:17 +0100 Original-Received: from localhost ([::1]:50898 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RXyhh-0005Rz-0f for ged-emacs-devel@m.gmane.org; Tue, 06 Dec 2011 12:21:17 -0500 Original-Received: from eggs.gnu.org ([140.186.70.92]:41066) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RXyhe-0005Rq-KV for emacs-devel@gnu.org; Tue, 06 Dec 2011 12:21:15 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RXyhd-0000c8-GF for emacs-devel@gnu.org; Tue, 06 Dec 2011 12:21:14 -0500 Original-Received: from mtaout22.012.net.il ([80.179.55.172]:39733) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RXyhd-0000bh-98 for emacs-devel@gnu.org; Tue, 06 Dec 2011 12:21:13 -0500 Original-Received: from conversion-daemon.a-mtaout22.012.net.il by a-mtaout22.012.net.il (HyperSendmail v2007.08) id <0LVS00300KEWT200@a-mtaout22.012.net.il> for emacs-devel@gnu.org; Tue, 06 Dec 2011 19:21:11 +0200 (IST) Original-Received: from HOME-C4E4A596F7 ([77.124.38.165]) by a-mtaout22.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0LVS003LNLJ96160@a-mtaout22.012.net.il>; Tue, 06 Dec 2011 19:21:10 +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:146509 Archived-At: > From: Stefan Monnier > Date: Tue, 06 Dec 2011 08:29:06 -0500 > Cc: emacs-devel@gnu.org > > 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... ??? Don't we free interval nodes that point into a buffer that is killed? Why would we need to keep them around? Anyway, the theory behind this experiment is that inserting lots of text in small chunks causes massive reallocations, one each for every time you fill the gap, and this fragmentation of the memory, which then makes it impossible to release more than the last 60MB. > Emacs should be perfectly able to reuse it next time it needs memory for > cons cells, strings, interval nodes, ... Actually, it seems to reuse even the fragmented chunks left from previous buffer reallocations. > E.g. re-running the same compilation should not significantly grow the > Emacs process (other than the extra 60MB, of course). That's what I saw, indeed.