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: Tue, 25 Oct 2016 05:02:33 -0400 Message-ID: <54AAC13A-CF56-4393-A932-DC6CBBF51259@raeburn.org> References: <87eg51ng4r.fsf_-_@users.sourceforge.net> <87k2djwumn.fsf@users.sourceforge.net> <83h98nidvd.fsf@gnu.org> <87eg3rvtsf.fsf@users.sourceforge.net> <83k2dihpm9.fsf@gnu.org> <8760p2wzgj.fsf@users.sourceforge.net> <838ttyhhzu.fsf@gnu.org> <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> 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 1477386201 30152 195.159.176.226 (25 Oct 2016 09:03:21 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 25 Oct 2016 09:03:21 +0000 (UTC) Cc: Eli Zaretskii , emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Oct 25 11:03:13 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 1byxdD-0004f0-Cr for ged-emacs-devel@m.gmane.org; Tue, 25 Oct 2016 11:02:51 +0200 Original-Received: from localhost ([::1]:52759 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1byxdF-0006wc-RS for ged-emacs-devel@m.gmane.org; Tue, 25 Oct 2016 05:02:53 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:46791) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1byxd3-0006vN-Km for emacs-devel@gnu.org; Tue, 25 Oct 2016 05:02:47 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1byxcy-0002Aa-Us for emacs-devel@gnu.org; Tue, 25 Oct 2016 05:02:41 -0400 Original-Received: from mail-qk0-x22a.google.com ([2607:f8b0:400d:c09::22a]:37656) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1byxcy-0002AR-PR for emacs-devel@gnu.org; Tue, 25 Oct 2016 05:02:36 -0400 Original-Received: by mail-qk0-x22a.google.com with SMTP id w69so15808031qka.4 for ; Tue, 25 Oct 2016 02:02:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=raeburn-org.20150623.gappssmtp.com; s=20150623; h=subject:mime-version:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=eeXa6GIo9AMeHtIZ5hbtfQriDbnNFtlmgxZLvwVcM9Q=; b=11WLqPWyEjIwUhX/Mg2vnbEEyOmD7eCkoyMFkJKScgDhtdFUDiZlP2bTPjLPIUJ0Uh g+H7bhyzLlIN1I25RjTJwB/13V2sd+91snUGEFzggeKL1ByJE+XzH89TMfar8nlzMjCk 39p/eh8RB5KkVA2vyqe/KI1vyc6YpzxYhX/GB4vSp/oaAht42EXEzVsaKGaVtf2QBKqp oR17p/PfoXM6hKJZa5RvW+9JzOzN+2DYX8Qbz4jNeutqXbbksIiL+UCVojbWmHzdnWdD rqGSvF9UN23i/9OSrdssAGzM1Pq4FfSmEQSFEwfEordyL5q0oaoR5tdHsTgzIOuGLaQu B6pg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:mime-version:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=eeXa6GIo9AMeHtIZ5hbtfQriDbnNFtlmgxZLvwVcM9Q=; b=Zs0B17BFtWgNl9GflX0FQ7zEZtMmvzdbMn4NyoWXZYBpI0pyARTZqCbZbVxW72/b7B PE6g6RsPFZiIFywHxRSU+g6LAq7XljfNCRC4JTibNJRg87oFXT8zACIQqRy34s2y8jNi WtGI0iWQG6aFL/83fCaPavDG6+sZGKEoSzyvCVOSQOYZs+ul1Ru0rHiXyNDK7IrFUuYM bUBZ/BFJTz0obXpTIuyaaixubA3Ms7c9DvTZ95U5/ELlbxetiw8lmqgWveB7J8jVo4K5 0bR8mddtadwcSvhidG2l4xxDawp6m1JCypq43VpeoP2MdbMPpDYbyGDhcKsIJdqM5F97 mssw== X-Gm-Message-State: ABUngvcKm0j3hd3wLut1ljbVmsp1ayP2CFh8vVMMIm6lmwcLUQTmIqGVLw6RXUPai/ft0A== X-Received: by 10.55.122.71 with SMTP id v68mr20364655qkc.176.1477386155884; Tue, 25 Oct 2016 02:02:35 -0700 (PDT) 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 l73sm10588470qke.26.2016.10.25.02.02.34 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 25 Oct 2016 02:02:35 -0700 (PDT) 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] X-Received-From: 2607:f8b0:400d:c09::22a 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:208755 Archived-At: On Oct 24, 2016, at 09:13, Stefan Monnier = wrote: >> Did you check whether actually byte compiling the written file made >> a difference? >=20 > dumped.elc has no code to compile. It has a lot of fset and setplist calls which can be compiled, = especially if you reorder things such that they=E2=80=99re not mixed up = with the defvar calls that don=E2=80=99t compile. The generated .elc = output is about 25% larger. I don=E2=80=99t expect the C parts of fset = and setplist to be affected at all, of course; the parsing and = interpretation of the Lisp may be another matter. Unfortunately, = byte-compile-file doesn=E2=80=99t preserve the sharing of objects = (=E2=80=9C#42#=E2=80=9D) present in the input file, so the output = isn=E2=80=99t semantically the same. I did some profiling. Without byte compiling, it appears that around = half of the CPU time used loading the file in my test is spent in = Frassq(=E2=80=A6,read_objects), called from substitute_object_recurse. = For processing a file with this much sharing of objects, an assoc list = with O(n) access time may not be the best choice. Whatever we replace = it with, it appears we need to be able to look up cons cells in a = collection by either element. The next top users of CPU time (_IO_getc, oblookup) are less = significant, though there are some easy minor gains to be made there. With a hacked-up 31-slot hash table replacing read_objects, the = getc_unlocked changes, and setting OBARRAY_SIZE to 8191, I got the load = time for the file in batch mode on my test system from just under a half = second to about a quarter second. Nearly half the remaining CPU time is = split between readchar, read1, readbyte_from_file, and Fassq. Ken=