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: Thu, 15 Dec 2011 01:04:01 -0500 Message-ID: References: <4ED0F945.5090805@yandex.ru> <83pqge7syw.fsf@gnu.org> <87mxb6tkji.fsf@wanadoo.es> <87borlu0kc.fsf@wanadoo.es> <83bora328r.fsf@gnu.org> <87mxauh20m.fsf@wanadoo.es> Reply-To: Eli Zaretskii NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Trace: dough.gmane.org 1323929053 10819 80.91.229.12 (15 Dec 2011 06:04:13 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Thu, 15 Dec 2011 06:04:13 +0000 (UTC) Cc: emacs-devel@gnu.org To: =?utf-8?Q?=C3=93scar?= Fuentes Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Dec 15 07:04:09 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 1Rb4QJ-0006D4-CR for ged-emacs-devel@m.gmane.org; Thu, 15 Dec 2011 07:04:07 +0100 Original-Received: from localhost ([::1]:52795 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Rb4QI-0006ip-F9 for ged-emacs-devel@m.gmane.org; Thu, 15 Dec 2011 01:04:06 -0500 Original-Received: from eggs.gnu.org ([140.186.70.92]:39577) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Rb4QG-0006iX-2V for emacs-devel@gnu.org; Thu, 15 Dec 2011 01:04:05 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Rb4QE-0003Ef-W4 for emacs-devel@gnu.org; Thu, 15 Dec 2011 01:04:04 -0500 Original-Received: from fencepost.gnu.org ([140.186.70.10]:43048) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Rb4QE-0003Ea-Ob for emacs-devel@gnu.org; Thu, 15 Dec 2011 01:04:02 -0500 Original-Received: from eliz by fencepost.gnu.org with local (Exim 4.71) (envelope-from ) id 1Rb4QD-0001Fm-O0; Thu, 15 Dec 2011 01:04:01 -0500 In-reply-to: <87mxauh20m.fsf@wanadoo.es> (message from =?utf-8?Q?=C3=93sca?= =?utf-8?Q?r?= Fuentes on Thu, 15 Dec 2011 05:50:17 +0100) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-Received-From: 140.186.70.10 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:146722 Archived-At: > From: Óscar Fuentes > Date: Thu, 15 Dec 2011 05:50:17 +0100 > > > 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. OK, let's agree these cases are rare. > 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.) It has never been proven that just growing a buffer in small chunks has this effect. Stefan thinks the reason is intervals. I'm not sure he is right (but I'm not an expert on this). I want to play with the examples posted here to trace what they do to memory allocation, but I need to find time to do it. If someone has time and motivation, it would help to trace through the various memory-allocation routines in those cases and report the results. FWIW, I always have at least one buffer in auto-revert-mode (it watches my .bzr.log file), and the memory footprint is still quite moderate, see my previous message. > 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. I don't understand where you see hand-waving. Reports about excessive memory consumption in real-life usage, like in Emacs running normally doing the usual stuff, are taken very seriously. They are hard to track down, especially if they happen on systems whose users cannot provide hard facts because they lack the ability to dig into the code with a debugger. This could explain slow progress, or no progress at all, in solving these problems. But no one hand-waves them under the carpet; saying so is simply unfair.