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: Sun, 11 Dec 2016 08:34:01 -0500 Message-ID: References: <871szqwu51.fsf@users.sourceforge.net> <831szqhbc2.fsf@gnu.org> <87d1itt79z.fsf_-_@users.sourceforge.net> <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> 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 1481463352 22995 195.159.176.226 (11 Dec 2016 13:35:52 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sun, 11 Dec 2016 13:35:52 +0000 (UTC) To: Emacs developers Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Dec 11 14:35:47 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 1cG4I6-0004by-IO for ged-emacs-devel@m.gmane.org; Sun, 11 Dec 2016 14:35:46 +0100 Original-Received: from localhost ([::1]:55709 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cG4I9-0000ss-3B for ged-emacs-devel@m.gmane.org; Sun, 11 Dec 2016 08:35:49 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:42198) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cG4HU-0000qF-VD for emacs-devel@gnu.org; Sun, 11 Dec 2016 08:35:10 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cG4HR-0008Ji-PZ for emacs-devel@gnu.org; Sun, 11 Dec 2016 08:35:09 -0500 Original-Received: from mail-qk0-f180.google.com ([209.85.220.180]:36497) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1cG4HR-0008JY-JE for emacs-devel@gnu.org; Sun, 11 Dec 2016 08:35:05 -0500 Original-Received: by mail-qk0-f180.google.com with SMTP id n21so60378614qka.3 for ; Sun, 11 Dec 2016 05:35:05 -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=UyczB2nh8UEwL4KqWcJIVkMKjquv8XaPr6DiesJw2k8=; b=zqfjeq31WLSgn3+BU9EvCfYo68rx9lyU2FZCuLtmp8scur+kD2GcsoI2Ht08QqJxT/ KrNTCyBdETN58FO8qRx8M+vMfvk870JlCANiZYAIqH7UJS9KxG425yoytTU/XswuEnok TYcikqSsDrcYINLjXKUokT58k9C4LVBBWB5fDha7GprrCxrUH8MTQnxT8GIZeXZ7fI5B YLq6LIzvQQ00hlUBqpPXWSbBvLavtJaBYP8phm0SbM/nsyEzD1esAF6F1fJ81svry169 oerocyedPgfCe7p+AuHnDJFh61+xmX8zYnZVMZKTSnFePCF/w/vBGH4GnaotfWJKJA44 cToQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to; bh=UyczB2nh8UEwL4KqWcJIVkMKjquv8XaPr6DiesJw2k8=; b=Jkv//3MoRqXaBHa+ifOhAO8s+G57P0NB840pTR2heOM2mRSsgXQAhO+dfe3Hm7dSA9 tS7DuQImjdapkA6yqnHqCvaK6m/wb2iIsOIbk8UsLTj88doIexHBdhfTJ2FkTHwgg5Mt dOk5nIZ7aRazrQO19tpfVL/4KXeA9fthytC4J+EQoCf0tzSzqKTspoLfHNoPNSiE9nFT ouNL5gkxzj47fLpxICITnv5nCqdjsbVIHEbXNrCm34vfIt3+3AbMbwRiq/aicSflTasi lwmFNVYLS9ZRa65YiOwG0QK/lmtaRRXffyQCf62VMsI9oS89VIdlHgoioe3E9A9c+76e a2rw== X-Gm-Message-State: AKaTC00ye68ksBRSd5rYfVZzaRjKGk03Yp3QzK0HWd85ZSwIATjsjGxmp25VrwYX11IVLg== X-Received: by 10.55.50.213 with SMTP id y204mr84956208qky.146.1481463244466; Sun, 11 Dec 2016 05:34:04 -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 t124sm24270721qke.3.2016.12.11.05.34.03 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Sun, 11 Dec 2016 05:34:03 -0800 (PST) In-Reply-To: <9463F91F-DB82-48E1-BE01-1E2BC8DA0766@raeburn.org> 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.220.180 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:210268 Archived-At: I=E2=80=99ve pushed an update to the scratch/raeburn-startup branch. It = includes several updates: * Stefan=E2=80=99s Oct 31 patch instead of his earlier one. This does = more reinitializing of charsets, coding systems, etc., which I believe = were absent from the previous version. * More patches to the recursive object substitution pass done during = reading. The big costs on Mac OS X seem to differ from my Linux/GNU/X11 = build =E2=80=94 there=E2=80=99s a much larger dumped.elc file, and an = entirely different compiler =E2=80=94 but I=E2=80=99ve managed to trim = the run time there a bit. * Changed gc-cons-threshold to be much larger. By itself, this isn=E2=80=99= t a good change. But we=E2=80=99d exceed the old value many times over = just reading the big =E2=80=9Cprogn=E2=80=9D form; this way my = Linux/GNU/X11 run doesn=E2=80=99t trigger GC during startup, though I = think the Mac version still does. I think a better strategy might try = to defer or discourage GC during startup, and do it instead when we have = idle cycles while the user isn=E2=80=99t trying to get something done. = But revamping the GC strategy is a different discussion. * Larger obarray. After startup, my Linux/GNU/X11 build has over 15k = symbols, and my Mac build has over 21k. The old obarray size of 1511 = meant average chain lengths of over 10 and 14. Shorter chains mean less = time spent in oblookup. And extra slots are cheap. * Open-code reading ASCII symbol characters from a file in read1(). The = hot path involved examining readcharfun to determine its type, compare = it against some known symbols, select a function to call, have that = function check to see if we=E2=80=99re doing pushback instead of = actually reading, block input, do the actual getc() call, and unblock = input =E2=80=94 all for each character. The new version duplicates a = bunch of code, but once it sees we=E2=80=99re reading from a file, skips = most of that for the common path through the inner loop. This cut maybe = 10% off of some of my run times. With all these changes =E2=80=94 Stefan=E2=80=99s new patch with = additional initialization, and my updates to shave a little more time = off =E2=80=94 I=E2=80=99m still hitting just under 0.2s for: time ./temacs --batch --eval '(progn (message "hi") (kill-emacs))' on Linux/GNU/X11 (Intel Core i5-2320, 3GHz, gcc 4.9); my Mac (Intel Core = 2 Duo, 2.8GHz) takes over half a second (including at least one GC = invocation). It can be tested by running =E2=80=9Ctemacs=E2=80=9D after building it. = The lisp load path will be set based on the source tree, not the = installation prefix. If =E2=80=9C-nl=E2=80=9D and =E2=80=9C-l=E2=80=9D = arguments are not given, it=E2=80=99ll load =E2=80=9C../src/dumped.elc=E2=80= =9D, but that=E2=80=99s interpreted relative to the lisp *source* = directory. If you build in a directory other than the checked-out tree = (i.e., $srcdir is not =E2=80=9C.=E2=80=9D) as I do, you=E2=80=99ll need = to copy dumped.elc from the src directory of the build tree where it=E2=80= =99s generated to the src directory of the source tree where it=E2=80=99s = sought. If dumped.elc isn=E2=80=99t found, temacs will exit with status 42. = Under Stefan=E2=80=99s version, an X11 run would spit out a message = saying the file wasn=E2=80=99t found and exit, but a tty run would get = into a loop complaining about internal-echo-keystrokes-prefix and would = need to be killed from another terminal. This way, it only kind of = sucks, equally in both cases. :-) The remaining time still seems to be about 2/3 reading and parsing = bytes, allocating objects, and updating (mostly scanning) the obarray. = There should be a bit more time that can be squeezed out. Ken