From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Dmitry Gutov Newsgroups: gmane.emacs.devel Subject: Re: /srv/bzr/emacs/emacs-24 r111116: eval-after-load fix Date: Sat, 05 Jan 2013 02:32:49 +0400 Message-ID: <50E75891.7070004@yandex.ru> References: <878v8b839k.fsf@yandex.ru> <871ue3c5ek.fsf@uwakimon.sk.tsukuba.ac.jp> <50E669D2.6030808@yandex.ru> <87sj6hb4f0.fsf@uwakimon.sk.tsukuba.ac.jp> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1357338782 19203 80.91.229.3 (4 Jan 2013 22:33:02 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 4 Jan 2013 22:33:02 +0000 (UTC) Cc: "Stephen J. Turnbull" , emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Jan 04 23:33:18 2013 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1TrFpF-0003Oi-Ax for ged-emacs-devel@m.gmane.org; Fri, 04 Jan 2013 23:33:17 +0100 Original-Received: from localhost ([::1]:45755 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TrFoz-0004NL-UB for ged-emacs-devel@m.gmane.org; Fri, 04 Jan 2013 17:33:01 -0500 Original-Received: from eggs.gnu.org ([208.118.235.92]:37129) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TrFos-0004Lp-Qi for emacs-devel@gnu.org; Fri, 04 Jan 2013 17:33:00 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TrFoo-0007Ub-Qt for emacs-devel@gnu.org; Fri, 04 Jan 2013 17:32:54 -0500 Original-Received: from mail-la0-f52.google.com ([209.85.215.52]:44009) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TrFoo-0007US-IB for emacs-devel@gnu.org; Fri, 04 Jan 2013 17:32:50 -0500 Original-Received: by mail-la0-f52.google.com with SMTP id fq12so10309212lab.25 for ; Fri, 04 Jan 2013 14:32:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:sender:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=arYtWcVjpe5Px5QGfBO+aMTjN2QL88oRDsixRBFRn5c=; b=zlzxJYisNbVtfVIXasCpItw0Rj4Dt0WYpcleJt5pC7E8ByKqFtAYbF6DpCHS7P6xZF lfpfu9RomHxZByPeZXw9qt3lR1rEviSb3QAuIDfPGf2CyRIPaFn7JUmJ9dRbFLbqijkx IK7nbmEeaeWpzQ3EG88LMR0mLW/mgYJyjMy5EGK4jU2Y19lWgRWyQHy6yp0hc4hlkXQI dBwtcmzktzdGr5uny4fJjBWwn/9FbzloOEpFHSBP8WSvpqxrZhWHixQRT3rXqQ3NEAkm WULDV0oFlqENuqggVFqbk21WX03LJOUVidTG46oUOMl+mapv3lljMN9udEPqjlStG9OQ C86g== X-Received: by 10.152.144.130 with SMTP id sm2mr51568647lab.49.1357338769394; Fri, 04 Jan 2013 14:32:49 -0800 (PST) Original-Received: from [127.0.0.1] ([178.252.98.87]) by mx.google.com with ESMTPS id tq10sm19262549lab.8.2013.01.04.14.32.46 (version=SSLv3 cipher=OTHER); Fri, 04 Jan 2013 14:32:47 -0800 (PST) User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0 In-Reply-To: X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x [fuzzy] X-Received-From: 209.85.215.52 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:156086 Archived-At: On 04.01.2013 22:10, Stefan Monnier wrote: >> The arguments that killed purespace for us were (1) most users >> (including most of those who argued for keeping purespace :-) are in >> one-xemacs-process-per-machine workflows, and (2) in theory modern >> virtual memory management by OSes (we were specifically influenced by >> Linux and Windows) should produce most of the benefits of purespace >> anyway, since the dumped code contains only a few writable objects, >> and those tend to be clumped on a very few pages per file, such that >> the potentially written pages might be measured in 100s of KB out of >> the 3-5 MB (at that time) of XEmacs memory. >> I'm not sure I believe (2), though. > > I also doubt 2 is true, unless XEmacs's object layout has been changed > to move the markbit out of their objects. All live objects's markbits > get written during a GC (except for purespace, of course), regardless of > the object being read-only. > > But I don't see this sharing as tremendously important: we're talking > about a purespace of about 2MB, for a process whose code size is larger > and whose minimal runtime size is also a good bit larger. > Negligible? I don't know! but not terribly important. > > OTOH the GC time at start up is reduced by almost a factor 3 (the Lisp > heap size of "emacs -Q" is about 1MB, whereas it'd be around 3MB if it > weren't for the purespace). On the third hand, this Gnus process has > a Lisp heap size of about 100MB, so the purespace makes virtually no > difference (we'd need a generational GC, instead). So, it seems to me the main beneficiary of purespace should be code that launches short-lived Emacs subprocesses, like John Wiegley's emacs-async package. I wonder if we can get some numbers on its performance with and without purespace.