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: Emacs bzr memory footprint Date: Fri, 21 Oct 2011 10:19:18 +0200 Message-ID: <83aa8usqnt.fsf@gnu.org> 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> Reply-To: Eli Zaretskii NNTP-Posting-Host: lo.gmane.org X-Trace: dough.gmane.org 1319185170 24959 80.91.229.12 (21 Oct 2011 08:19:30 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Fri, 21 Oct 2011 08:19:30 +0000 (UTC) Cc: jwiegley@gmail.com, emacs-devel@gnu.org To: Nix Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Oct 21 10:19:26 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 1RHAK5-0004QL-5Q for ged-emacs-devel@m.gmane.org; Fri, 21 Oct 2011 10:19:25 +0200 Original-Received: from localhost ([::1]:60342 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RHAK4-0004dZ-6R for ged-emacs-devel@m.gmane.org; Fri, 21 Oct 2011 04:19:24 -0400 Original-Received: from eggs.gnu.org ([140.186.70.92]:50282) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RHAK0-0004d3-8R for emacs-devel@gnu.org; Fri, 21 Oct 2011 04:19:21 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RHAJy-0005Ps-KJ for emacs-devel@gnu.org; Fri, 21 Oct 2011 04:19:20 -0400 Original-Received: from mtaout21.012.net.il ([80.179.55.169]:64938) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RHAJy-0005Pj-8X for emacs-devel@gnu.org; Fri, 21 Oct 2011 04:19:18 -0400 Original-Received: from conversion-daemon.a-mtaout21.012.net.il by a-mtaout21.012.net.il (HyperSendmail v2007.08) id <0LTE00100PRONB00@a-mtaout21.012.net.il> for emacs-devel@gnu.org; Fri, 21 Oct 2011 10:19:16 +0200 (IST) Original-Received: from HOME-C4E4A596F7 ([77.124.212.197]) by a-mtaout21.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0LTE0014UPS2MZ20@a-mtaout21.012.net.il>; Fri, 21 Oct 2011 10:19:16 +0200 (IST) In-reply-to: <87ty73mc0m.fsf@spindle.srvr.nix> X-012-Sender: halo1@inter.net.il X-detected-operating-system: by eggs.gnu.org: Solaris 10 (beta) X-Received-From: 80.179.55.169 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:145381 Archived-At: > From: Nix > Emacs: well, why *shouldn't* you pay property taxes on your editor? > Date: Fri, 21 Oct 2011 01:19:53 +0100 > Cc: emacs-devel@gnu.org > > On second thought, IIRC Gnus allocates some very large lists as part of > its overview management or something: perhaps this is serving to spam > the arena with a huge number of (individually small, thus not > mmap()-allocated) atoms which, when they get freed later, produce a very > sparsely-filled, severely-fragmented heap? If so, perhaps Emacs would > benefit from a simple pool allocator accessed via a new let/setq form or > a new arg to create-buffer, so Gnus could arrange to stuff variables it > knows will be huge, or buffer-local variables of buffers it thinks may > have lots of huge buffer-local vars, into a newly-mmap()ed region? > Unfortunately that means, sigh, using our own malloc() again, which is > probably more painful than useful. I suspect actually proving my > contention first would be a good idea. Not sure how to get the addresses > of Lisp objects from a running Emacs though: gdb, presumably. Do you see a similar growth of the footprint in Emacs 23.3? None of what you are describing seems to be specific to Emacs 24, so it would be good to compare with the memory usage of Emacs 23.3. As for memory fragmentation: this is on GNU/Linux, right? If so, the memory allocator used by Emacs should prevent any such fragmentation, at least in the simple scenarios you described. So I don't think memory fragmentation can explain what you see.