From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Nix Newsgroups: gmane.emacs.devel Subject: Re: Emacs bzr memory footprint Date: Fri, 21 Oct 2011 20:11:29 +0100 Message-ID: <87k47ykvmm.fsf@spindle.srvr.nix> References: <83fwix2osa.fsf@gnu.org> <0B3EE7A4-D0D6-4D1E-ADC4-0BEE68F179B2@mit.edu> <87fwivwp37.fsf@turtle.gmx.de> <87sjmvpmd2.fsf@lifelogs.com> <87aa93wmc4.fsf@turtle.gmx.de> <87sjmnrdjw.fsf@spindle.srvr.nix> <87ty73mc0m.fsf@spindle.srvr.nix> <4EA19111.7060401@yandex.ru> <87r526yzcf.fsf@wanadoo.es> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Trace: dough.gmane.org 1319224304 16145 80.91.229.12 (21 Oct 2011 19:11:44 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Fri, 21 Oct 2011 19:11:44 +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 Fri Oct 21 21:11:40 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 1RHKVF-0000ER-4C for ged-emacs-devel@m.gmane.org; Fri, 21 Oct 2011 21:11:37 +0200 Original-Received: from localhost ([::1]:37080 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RHKVE-0005Pq-Aw for ged-emacs-devel@m.gmane.org; Fri, 21 Oct 2011 15:11:36 -0400 Original-Received: from eggs.gnu.org ([140.186.70.92]:43875) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RHKVC-0005Pe-6z for emacs-devel@gnu.org; Fri, 21 Oct 2011 15:11:35 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RHKVA-00024X-UM for emacs-devel@gnu.org; Fri, 21 Oct 2011 15:11:34 -0400 Original-Received: from icebox.esperi.org.uk ([81.187.191.129]:49648 helo=mail.esperi.org.uk) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RHKVA-00023l-Lq for emacs-devel@gnu.org; Fri, 21 Oct 2011 15:11:32 -0400 Original-Received: from esperi.org.uk (nix@spindle.srvr.nix [192.168.14.15]) by mail.esperi.org.uk (8.14.5/8.14.5) with ESMTP id p9LJBTU4017117; Fri, 21 Oct 2011 20:11:29 +0100 Original-Received: (from nix@localhost) by esperi.org.uk (8.14.5/8.14.5/Submit) id p9LJBT7c016047; Fri, 21 Oct 2011 20:11:29 +0100 Emacs: Lovecraft was an optimist. In-Reply-To: <87r526yzcf.fsf@wanadoo.es> (=?utf-8?Q?=22=C3=93scar?= Fuentes"'s message of "Fri, 21 Oct 2011 20:27:28 +0200") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.90 (gnu/linux) X-DCC-URT-Metrics: spindle 1060; Body=2 Fuz1=2 Fuz2=2 X-MIME-Autoconverted: from 8bit to quoted-printable by mail.esperi.org.uk id p9LJBTU4017117 X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 81.187.191.129 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:145409 Archived-At: On 21 Oct 2011, =C3=93scar Fuentes told this: > The memory for the text of a buffer, is a single chunk? Or, more > generally, are large chunks of memory allocated for big buffers? If the > answer is yes, memory fragmentation may be problematic for those who > work with large buffers, unless the allocating algorithm avoids that. Emacs goes to some lengths to avoid allocating memory on the brk()ed heap for buffers of significant size. The rules are somewhat arcane. On a limited number of platforms (currently Cygwin, FreeBSD and IRIX 6.5), mmap() is used to map buffer text directly. On platforms using the copy of Doug Lea's malloc() in src/gmalloc.c (or using Doug Lea's malloc without being a GNU system, if any such systems exist), buffers are allocated using the frankly terrifying block-relocating memory allocator in ralloc.c, which uses sbrk() directly and arranges for blocks allocated that way to dodge out of the way of malloc() using the morecore_hook. (I'd be scared to trust my data to this one.) On GNU platforms which appear to be using Doug Lea's malloc(), we turn this off and just use malloc() directly. Emacs relies on all of these allocating the buffer storage in a single (virtually) contiguous chunk (modulo the gap): the gap-motion code in insdel.c, and much else, depends on being able to use simple pointer arithmetic to move around the buffer. --=20 NULL && (void)