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 15:25:59 -0500 Message-ID: References: <4ED0F945.5090805@yandex.ru> <83pqge7syw.fsf@gnu.org> <87mxb6tkji.fsf@wanadoo.es> <4EDDED4B.7030607@yandex.ru> <8362htbos6.fsf@gnu.org> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: dough.gmane.org 1323203176 9809 80.91.229.12 (6 Dec 2011 20:26:16 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Tue, 6 Dec 2011 20:26:16 +0000 (UTC) Cc: dmantipov@yandex.ru, emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Dec 06 21:26: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 1RY1aY-0003RT-1Q for ged-emacs-devel@m.gmane.org; Tue, 06 Dec 2011 21:26:06 +0100 Original-Received: from localhost ([::1]:42394 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RY1aX-00081O-CI for ged-emacs-devel@m.gmane.org; Tue, 06 Dec 2011 15:26:05 -0500 Original-Received: from eggs.gnu.org ([140.186.70.92]:33950) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RY1aU-00081J-SN for emacs-devel@gnu.org; Tue, 06 Dec 2011 15:26:03 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RY1aT-000452-Jl for emacs-devel@gnu.org; Tue, 06 Dec 2011 15:26:02 -0500 Original-Received: from pruche.dit.umontreal.ca ([132.204.246.22]:47009) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RY1aT-00044s-Cs; Tue, 06 Dec 2011 15:26:01 -0500 Original-Received: from faina.iro.umontreal.ca (lechon.iro.umontreal.ca [132.204.27.242]) by pruche.dit.umontreal.ca (8.14.1/8.14.1) with ESMTP id pB6KPxD8008165; Tue, 6 Dec 2011 15:25:59 -0500 Original-Received: by faina.iro.umontreal.ca (Postfix, from userid 20848) id 85B64B42C1; Tue, 6 Dec 2011 15:25:59 -0500 (EST) In-Reply-To: <8362htbos6.fsf@gnu.org> (Eli Zaretskii's message of "Tue, 06 Dec 2011 19:20:09 +0200") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.92 (gnu/linux) X-NAI-Spam-Flag: NO X-NAI-Spam-Threshold: 5 X-NAI-Spam-Score: 0 X-NAI-Spam-Rules: 1 Rules triggered RV4063=0 X-NAI-Spam-Version: 2.2.0.9309 : core <4063> : streams <708377> : uri <1022951> 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:146515 Archived-At: >> 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? They should be put on the free list, but whether or not they're returned to the malloc library depends on whether or not block of those elements is fully free. I.e. like with most other Lisp data types. I think we could fairly easily change the code so that interval objects are not managed by the GC but my malloc instead. > 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. I doubt that's what happens. I think instead that the extra memory is what is used by the various text properties we add. It is true that Emacs makes request from malloc in "10KB" chunks for Lisp data, so any malloc fragment smaller than that can only be used for things like vectors I guess, but it doesn't seem sufficient to explain the effect we're seeing. Stefan