From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Ken Raeburn Newsgroups: gmane.emacs.devel Subject: Re: Skipping unexec via a big .elc file Date: Thu, 15 Dec 2016 12:28:15 -0500 Message-ID: <75C18644-F7C8-4164-BA46-CD73F4E39A93@raeburn.org> References: <7baa18d4-2b09-caa8-005e-29008a383ad1@cs.ucla.edu> <83mvhwrgd5.fsf@gnu.org> <8539f38f-9a11-44c3-4de7-bb974c96206c@cs.ucla.edu> <8360ojpndr.fsf@gnu.org> <83shrnm0k1.fsf@gnu.org> <075B0922-F07A-4FBA-AE71-027E964A5ED4@raeburn.org> <54AAC13A-CF56-4393-A932-DC6CBBF51259@raeburn.org> <3CC6BB36-1794-4202-8243-132E0345B236@raeburn.org> <52BDCC33-546C-4F47-A230-00EBC813B038@raeburn.org> <15CF14CC-C7DE-44BA-AC7D-F0BF1F160979@raeburn.org> <9463F91F-DB82-48E1-BE01-1E2BC8DA0766@raeburn.org> <5b39d866-16ea-8cf1-f25e-6bfc3304ac2a@cornell.edu> <16B1EC9C-9BF7-432E-BE42-154740B04679@raeburn.org> <00AE6236-2C0B-4E2A-8A53-16A5C42D41A9@raeburn.org> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Trace: blaine.gmane.org 1481822986 27054 195.159.176.226 (15 Dec 2016 17:29:46 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Thu, 15 Dec 2016 17:29:46 +0000 (UTC) To: Emacs developers Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Dec 15 18:29:43 2016 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cHZqd-0005rJ-Hi for ged-emacs-devel@m.gmane.org; Thu, 15 Dec 2016 18:29:39 +0100 Original-Received: from localhost ([::1]:56054 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cHZqe-00031f-S0 for ged-emacs-devel@m.gmane.org; Thu, 15 Dec 2016 12:29:40 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:60956) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cHZqP-0002ai-3A for emacs-devel@gnu.org; Thu, 15 Dec 2016 12:29:29 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cHZqK-0008Mj-3V for emacs-devel@gnu.org; Thu, 15 Dec 2016 12:29:25 -0500 Original-Received: from mail-qt0-f174.google.com ([209.85.216.174]:35734) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1cHZqJ-0008Lr-RB for emacs-devel@gnu.org; Thu, 15 Dec 2016 12:29:20 -0500 Original-Received: by mail-qt0-f174.google.com with SMTP id c47so63424878qtc.2 for ; Thu, 15 Dec 2016 09:29:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=raeburn-org.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to; bh=xQhRRd9+SkjabqwQ3Xcaf9BRScGaZ/UTrNnhyI+oNak=; b=0Ddj3qws7+KNoniWfglqA9eWeewMb1ywr1YESaKssyaKSGdLXAEyKFLLZVc+hgC1Qu v8AkYWRsOVOr+6B0/6f25pxSXWfdIuaoK8yl8RfF4QPFCbHM0v3etOVv7yCZb4YCnZO1 8flLjmTcW/pzreZBRX/ZnNkyks7BKrukgA+c03fOX0QsrsR5udUeXzLLD9WcibOn1Ors EGAQ9DzhJOv2X9A8N2LyJffV5CMKIq08kyLHqlZ0OOM63uQ669XTTJlJ2RM+QDRdl4Ga NmtcCdcZpncD/mHyJBYqDt073UqqAprpsDNaNYkB29xQ/iUrO8IGWw49yOBrupd3yZKG 7CcA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to; bh=xQhRRd9+SkjabqwQ3Xcaf9BRScGaZ/UTrNnhyI+oNak=; b=j+7aaZqar+z1cjxSQANYFtk13Hrx2JRRy9DLAbJ0i0y/DblV/Yd10kQ3T+JcmR8Je9 3j4e1nXj+3/gFLR3CZqchPc+dWRrpsY/KDcgNKM1v2MeTawwYkFJD142diCEpUfRD5Uh +ljwjmH5Bq2siMk2O8vU6L3cwfOXURF+UXUsDOEy688bqXjMMpAM0Sq2v1fH1AOoR4GD tWKS5tOzDVfEC56BlawQ44aVnxKaX+c/kUK/SxUyncfewX8PD4/IzdZl2ruNniXhZ3BO fb5B8w1N0ADUAzRR6cA4KniAjAHZLCgnMxQN9RPJ43zMGjThRaiKugk3K7D8rrWpfylT 1KfQ== X-Gm-Message-State: AIkVDXLZ9iIVlJyfRKoP2WojUIMJEkNptL/cQD4t3DcpdaKWWimlbPwzTz74Tdt4BJUrQA== X-Received: by 10.200.41.171 with SMTP id 40mr1898790qts.235.1481822898686; Thu, 15 Dec 2016 09:28:18 -0800 (PST) Original-Received: from [192.168.23.52] (c-50-138-183-136.hsd1.ma.comcast.net. [50.138.183.136]) by smtp.gmail.com with ESMTPSA id n79sm1538927qkn.15.2016.12.15.09.28.16 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 15 Dec 2016 09:28:17 -0800 (PST) In-Reply-To: X-Mailer: Apple Mail (2.3124) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] [fuzzy] X-Received-From: 209.85.216.174 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 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" Xref: news.gmane.org gmane.emacs.devel:210483 Archived-At: One area I=E2=80=99m contemplating now is whether we can trim the size = of dumped.elc. Question: How useable does Emacs need to be if the Lisp code is = improperly installed (or not installed) and can=E2=80=99t be loaded? With the big-elc approach as currently implemented, assuming we store = dumped.elc in the install tree along with the other Lisp code, it = basically can=E2=80=99t start without that Lisp library. If that=E2=80=99s okay, then the next question is: How much do we *need* = to load before processing user input? My impression has been that the current loadup.el contents cover not = just the bare minimum that Emacs absolutely needs to have to function, = but also the popular things we want to have readily available without = having to wait for a Lisp package to load (like buff-menu), especially = if it=E2=80=99s in response to a simple keypress or mouse click. (The X = support code is loaded in an X build, even if no X display is present at = startup; I think parts of it fall into both categories.) And adding = stuff is fairly cheap; loadup and unexec can take as long as they want, = only the speed of relaunching the resulting executable affects the user. With the big-elc approach, the tradeoffs change. Reading a bunch of = function definitions from dumped.elc is only a tiny bit faster than = reading the same definitions from the original .elc files, because we = don=E2=80=99t have to open more files. (At least, the cost is trivial = if the files are in cache. It=E2=80=99ll be OS- and system-dependent.) = Only the time for precomputation that gets done as the file is loaded is = saved, and exchanged for the time needed to parse the saved result. If we can trim some stuff from loadup.el, and resort to autoloading that = stuff later, that may save us some startup time. (Some text mode = commands? Or buff-menu?) If we really want some of the other stuff to be able to run immediately = when the user hits a key, maybe there=E2=80=99s some way to compromise = between that and faster startup. A strawman proposal: load the = =E2=80=9Cmust-haves=E2=80=9D via dumped.elc; load the user=E2=80=99s = init file, read files and execute eval commands as indicated by the = command line options; check for user input; if there=E2=80=99s no user = input (e.g., use an idle timer set for 3s), start going through a list = of =E2=80=9Cnice-to-haves=E2=80=9D and loading them, continuing until = user input is available. If the user starts typing or otherwise = invoking some of those nice-to-have commands right away, they=E2=80=99ll = have to wait while autoloading happens, but if we get a couple idle = seconds, we may still pull the commands in before the user needs them. Of course, if the user types something while we=E2=80=99re loading a = file, that file will have to finish loading before we can respond; = it=E2=80=99s sort of a guessing game as to how much idle time suggests = that the user is doing something else and probably won=E2=80=99t type = anything in the next second or two. Perhaps we can divide the task = further to keep any individual delay shorter: read a .elc file into a = buffer, check for input, parse into S-expressions, check for input, eval = the S-expressions=E2=80=A6 Ken=