From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: =?utf-8?Q?=C3=93scar_Fuentes?= Newsgroups: gmane.emacs.devel Subject: Re: Memory again Date: Thu, 15 Dec 2011 05:50:17 +0100 Message-ID: <87mxauh20m.fsf@wanadoo.es> References: <4ED0F945.5090805@yandex.ru> <83pqge7syw.fsf@gnu.org> <87mxb6tkji.fsf@wanadoo.es> <87borlu0kc.fsf@wanadoo.es> <83bora328r.fsf@gnu.org> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: dough.gmane.org 1323924643 20986 80.91.229.12 (15 Dec 2011 04:50:43 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Thu, 15 Dec 2011 04:50:43 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Dec 15 05:50:39 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 1Rb3HC-0002KA-6Z for ged-emacs-devel@m.gmane.org; Thu, 15 Dec 2011 05:50:38 +0100 Original-Received: from localhost ([::1]:53725 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Rb3HB-00027m-MD for ged-emacs-devel@m.gmane.org; Wed, 14 Dec 2011 23:50:37 -0500 Original-Received: from eggs.gnu.org ([140.186.70.92]:50789) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Rb3H7-00027L-V7 for emacs-devel@gnu.org; Wed, 14 Dec 2011 23:50:35 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Rb3H6-0006wl-HK for emacs-devel@gnu.org; Wed, 14 Dec 2011 23:50:33 -0500 Original-Received: from lo.gmane.org ([80.91.229.12]:54759) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Rb3H6-0006wf-8W for emacs-devel@gnu.org; Wed, 14 Dec 2011 23:50:32 -0500 Original-Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1Rb3H4-0002Hu-2k for emacs-devel@gnu.org; Thu, 15 Dec 2011 05:50:30 +0100 Original-Received: from 63.red-81-43-217.staticip.rima-tde.net ([81.43.217.63]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 15 Dec 2011 05:50:30 +0100 Original-Received: from ofv by 63.red-81-43-217.staticip.rima-tde.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 15 Dec 2011 05:50:30 +0100 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 32 Original-X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: 63.red-81-43-217.staticip.rima-tde.net User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.91 (gnu/linux) Cancel-Lock: sha1:hRL8WdJBONAXV/H4FJKQwaxklc0= X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-Received-From: 80.91.229.12 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:146719 Archived-At: Eli Zaretskii writes: >> 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 version of Emacs is that, and on which OS? > > FWIW, my Emacs runs for many weeks if not months, has about 250 to 300 > buffers of various sizes, and never exceeds 200MB (usually levels out > at 170MB). I have a similar experience. >> By the way, the dismissal of this being a real problem because emacs can >> always reuse the fragmented memory either > > I don't think there's much fragmented memory in real-life use (barring > bugs). The test cases that exhibited a lot of fragmentation are all > toy examples that don't really happen. The case I described was real, although seldom happens here. I can think of typical scenarios where buffer size grows to large sizes: ERC sessions, files monitored with auto-revert(-tail)-mode... Even cases where the user makes a mistake that creates huge buffers (visiting a GNUs group with tens of thousands on unread messages, for instance.) Taking a selfish stance, I don't care about this problem because it is not harming me, but your response and Stefan's looks a lot like hand waving. Yes, it probably is hard to fix and there are more profitably tasks, but it *is* a real problem, not something a user made up for chatting about memory allocators on emacs-devel.