From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: CVS HEAD fails to build on OSX 10.4 (macterm.c broken?) Date: Wed, 05 Sep 2007 10:27:00 -0400 Message-ID: References: <86k5re4blv.fsf@blue.stonehenge.com> <200708291531.l7TFVnlD010335@oogie-boogie.ics.uci.edu> <86fy224aah.fsf@blue.stonehenge.com> <86bqcq4a4q.fsf@blue.stonehenge.com> <200708291604.l7TG4atk011108@oogie-boogie.ics.uci.edu> <867ine492x.fsf@blue.stonehenge.com> <200708291628.l7TGSvM6011975@oogie-boogie.ics.uci.edu> <200709042130.l84LU0x3007416@oogie-boogie.ics.uci.edu> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1189002450 1724 80.91.229.12 (5 Sep 2007 14:27:30 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Wed, 5 Sep 2007 14:27:30 +0000 (UTC) Cc: merlyn@stonehenge.com, eliz@gnu.org, Dan Nicolaescu , mituharu@math.s.chiba-u.ac.jp, emacs-devel@gnu.org To: rms@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Sep 05 16:27:30 2007 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1ISvqn-0005F1-0A for ged-emacs-devel@m.gmane.org; Wed, 05 Sep 2007 16:27:25 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1ISvql-0008C1-AC for ged-emacs-devel@m.gmane.org; Wed, 05 Sep 2007 10:27:23 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1ISvqb-00088N-FW for emacs-devel@gnu.org; Wed, 05 Sep 2007 10:27:13 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1ISvqZ-00087h-HS for emacs-devel@gnu.org; Wed, 05 Sep 2007 10:27:12 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1ISvqZ-00087Y-2y for emacs-devel@gnu.org; Wed, 05 Sep 2007 10:27:11 -0400 Original-Received: from tomts20.bellnexxia.net ([209.226.175.74] helo=tomts20-srv.bellnexxia.net) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1ISvqQ-0006q6-JY; Wed, 05 Sep 2007 10:27:02 -0400 Original-Received: from pastel.home ([70.53.192.250]) by tomts20-srv.bellnexxia.net (InterMail vM.5.01.06.13 201-253-122-130-113-20050324) with ESMTP id <20070905142701.UZOP8273.tomts20-srv.bellnexxia.net@pastel.home>; Wed, 5 Sep 2007 10:27:01 -0400 Original-Received: by pastel.home (Postfix, from userid 20848) id DE6A482E4; Wed, 5 Sep 2007 10:27:00 -0400 (EDT) In-Reply-To: (Richard Stallman's message of "Wed\, 05 Sep 2007 02\:16\:56 -0400") User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/23.0.50 (gnu/linux) X-Detected-Kernel: Solaris 8 (1) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:77861 Archived-At: > So what is the problem with having *-win loaded by default? > It isn't really a problem, it just wastes space by making Emacs bigger. > The tradeoff is that loading it when needed takes time. > I don't insist on changing it, but did anyone think about the question > in these terms? I must say I'm not sure why we do preloading (and dumping), so it's a more general question. In my view, there are two main reasons to preload: 1 - startup speed: I think this is clear enough to everybody. 2 - heap size: a bit less obvious; a preloaded package puts some of its information (mostly the bytecode) in the `pure' storage which is not garbage collected (and is generally slightly more compact, tho this is negligible), so the GC'd heap is slightly smaller than if the package had been loaded after dumping. 3 - page sharing between processes: the purespace can be shared (by the OS) between several Emacs instances. This is probably a rather rare situation nowadays, and the difference is likely to be negligible. 4 - resilience: if the `emacs' binary finds itself all alone (somehow all the other .elc files are unreadable/lost), an Emacs with preloaded packages is more likely to still be somewhat usable. Numbers 1,2,3 improve incrementally with each added preloaded package, as long as that package is almost always used. For any given package, the impact is likely to be minor, so measuring the impact of preloading a single package is likely to be futile (and very difficult because the impact will be lost in the noise). Number 4 improves less incrementally. Emacs may become fully unusable if some packages can't be found and are not preloaded. So number 4 seems to indicate that a package should be preloaded if in some circumstances the binary may become unusable in the case where the .elc files cannot be found. Stefan