From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Philipp Stephani Newsgroups: gmane.emacs.devel Subject: Re: Skipping unexec via a big .elc file Date: Sat, 08 Apr 2017 15:53:49 +0000 Message-ID: References: <8A8DA980-13A7-4F8B-9D07-391728C673C9@raeburn.org> <831su4dmn4.fsf@gnu.org> <87h9300x5n.fsf@linux-m68k.org> <734D2132-71FD-414D-B091-629189742DB4@raeburn.org> <83a8889ede.fsf@gnu.org> <144D5F87-D876-485D-BAB3-2AA93627272A@raeburn.org> <83inmq53xk.fsf@gnu.org> <96D35768-314C-43F5-BD5E-B12187759DCA@raeburn.org> <123104DD-447F-4CDB-B3A0-CED80E3AC8C9@raeburn.org> <20170403165736.GA2851@acm> <2497A2D5-FDB1-47FF-AED3-FD4ABE2FE144@raeburn.org> <83lgrhpalq.fsf@gnu.org> <0D99B4FE-FEEF-4565-87D6-E230A05DEF3C@raeburn.org> <86lgrc4vob.fsf@molnjunk.nocrew.org> <834ly0oew1.fsf@gnu.org> <968E8F50-92F6-43C7-B7E4-EE8378943087@raeburn.org> <83wpawmj4d.fsf@gnu.org> <1e397033-8291-1625-8b78-a1e1c200aea5@gmail.com> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=f403045f57f01d4448054ca9c0e8 X-Trace: blaine.gmane.org 1491666858 3522 195.159.176.226 (8 Apr 2017 15:54:18 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sat, 8 Apr 2017 15:54:18 +0000 (UTC) To: =?UTF-8?Q?Cl=C3=A9ment_Pit=2DClaudel?= , emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Apr 08 17:54:11 2017 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 1cwsgf-0007pT-50 for ged-emacs-devel@m.gmane.org; Sat, 08 Apr 2017 17:54:05 +0200 Original-Received: from localhost ([::1]:55629 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cwsgl-0007dC-1D for ged-emacs-devel@m.gmane.org; Sat, 08 Apr 2017 11:54:11 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:36518) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cwsgc-0007bi-Bv for emacs-devel@gnu.org; Sat, 08 Apr 2017 11:54:03 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cwsgb-0008O4-9S for emacs-devel@gnu.org; Sat, 08 Apr 2017 11:54:02 -0400 Original-Received: from mail-wr0-x234.google.com ([2a00:1450:400c:c0c::234]:34369) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1cwsga-0008No-Vi for emacs-devel@gnu.org; Sat, 08 Apr 2017 11:54:01 -0400 Original-Received: by mail-wr0-x234.google.com with SMTP id t20so125259534wra.1 for ; Sat, 08 Apr 2017 08:54:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=AQ68c+6ZlJwbj1MAFMhL279qaLtNpH3OV8N/oZeWOG0=; b=sSPT+CHBtnGtKEFBKt5bfpQ5rb914S40WLuIU2h461UIgktU12sKlia3CH7lfHPj6R KZaxNzuBntBrimYNNxa+qcwM2xe6ftKGxn0OonX6lWGtNUKUrlwzC1LlHGOfcu2i8+Sd sDJbusINADLOC2TX+Tr85g4hWBspC4L90oDBjLOedEi8YnIjl0OMqSPHy6v17XeCSWlD Fs/8Jm1twLpVl6SqH5uXSI9grJnyBbWDsGIJ+faEuzQVLmaNIRCyWC7X5VI9z47tLOr7 Z7PNTWELfVKkQIZFAaVmMbTUiM0bOCwmZS8bRFRK2PuoLzeuir+WIr1G4+zS6Yy9TK4Y Ybtw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=AQ68c+6ZlJwbj1MAFMhL279qaLtNpH3OV8N/oZeWOG0=; b=PXWQvOMRh6pHGQHztmE+EKv1TV3sl/kG3aAaAy3EWdScCUcNbFn1stxrm5tjute5uT OK7pQda3TKsMap9tGAfX6HsJ/fG0lVuNSSBfMDLdPeo/PMgBkO2CJLZNLahw9iOHE2mA VRezNwcEudkPn6qYY7AVhd5EAk2uKQCKhoO7QTg4JHjLBeDECcTO77eNm6tjfysmnjDj ++Mf3dlnS+eYOUIjkqQr3oyowArLXet8hXo2DafwBPsFDMYJ4OVKIKwC99nHqf4sth14 GWiewNZkY1pdxDBIHLajsKgOP1qNkWvn1HhEu6ZSEe8Zk1grCCWjjSodxfPWmVUZWVF+ sihA== X-Gm-Message-State: AN3rC/7YlRDKU2TxUgSsW2keA1iKW8Sz47uz0nRM/jFinFjRexbsFdXhcDLCQkQbShnsM5ltqKTKTLe2Qu92Qw== X-Received: by 10.223.154.70 with SMTP id z64mr12590277wrb.136.1491666839877; Sat, 08 Apr 2017 08:53:59 -0700 (PDT) In-Reply-To: <1e397033-8291-1625-8b78-a1e1c200aea5@gmail.com> X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2a00:1450:400c:c0c::234 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:213813 Archived-At: --f403045f57f01d4448054ca9c0e8 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cl=C3=A9ment Pit-Claudel schrieb am Sa., 8. Apr. 20= 17 um 17:15 Uhr: > On 2017-04-08 11:03, Philipp Stephani wrote: > > Cl=C3=A9ment Pit-Claudel >> =E2=80=A6 essentially everything in packages that were previously > >> preloaded needs to be autoloaded now, since many packages don't > >> (require) the preloaded features that they use. > > > Doesn't that effectively just move most of the code to loaddefs.el, > > from which it again has to be either preloaded or byte-compiled into > > the "big .elc file"? Does this really bring measurable benefits > > nowadays? > > (Sorry if I'm misunderstanding you) > > I think the idea is that you can defer loading the implementation of a > significant fraction of currently-preloaded functions, because many of > these are currently unused. > > So the intended saving is that currently-preloaded but uncommonly-used > functions would not be dumped to the big-elc (their signatures, in the fo= rm > an autoload, would be). Packages that use them without (require)-ing the > corresponding feature first would still work, but startup would be faster= . > The question is whether there is actually a significant speed-up. Autoloading is traditionally used for a small number of interactive commands that cause large optional libraries to be loaded. In such cases I could imagine that the performance gain is still significant. However, you now suggest that preloaded libraries get turned into autoloads. The structure of those libraries is typically quite different: the consist to a large extent of individual helper functions that are independent of each other. My guess is that this could make overall performance worse: it will cause loaddefs.el to contain all the signatures and docstrings of these helper functions, and loaddefs.el is itself not byte-compiled. Therefore, you now need to load the definitions effectively twice: once in loaddefs.el, once the functions are actually used. Therefore such a change shouldn't be made without measuring its impact. I'd actually prefer going into the other direction: preload much more than now, and remove lots of stuff from autoloads. This will probably need a different strategy for preloading (Daniel's approach, or Rmacs, or an Elisp LLVM compiler, ...). --f403045f57f01d4448054ca9c0e8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


Cl=C3= =A9ment Pit-Claudel <cpitclaude= l@gmail.com> schrieb am Sa., 8. Apr. 2017 um 17:15=C2=A0Uhr:
On 2017-04-08 11:03, Philipp Stephani wrot= e:
> Cl=C3=A9ment Pit-Claudel <cpitclaudel@gmail.com schrieb: >> =E2=80=A6 essentially everything in packages that were previously<= br class=3D"gmail_msg"> >> preloaded needs to be autoloaded now, since many packages don'= t
>> (require) the preloaded features that they use.

> Doesn't that effectively just move most of the code to loaddefs.el= ,
> from which it again has to be either preloaded or byte-compiled into > the "big .elc file"? Does this really bring measurable benef= its
> nowadays?

(Sorry if I'm misunderstanding you)

I think the idea is that you can defer loading the implementation of a sign= ificant fraction of currently-preloaded functions, because many of these ar= e currently unused.

So the intended saving is that currently-preloaded but uncommonly-used func= tions would not be dumped to the big-elc (their signatures, in the form an = autoload, would be).=C2=A0 Packages that use them without (require)-ing the= corresponding feature first would still work, but startup would be faster.=

The question is wh= ether there is actually a significant speed-up.
Autoloading is tr= aditionally used for a small number of interactive commands that cause larg= e optional libraries to be loaded. In such cases I could imagine that the p= erformance gain is still significant. However, you now suggest that preload= ed libraries get turned into autoloads. The structure of those libraries is= typically quite different: the consist to a large extent of individual hel= per functions that are independent of each other. My guess is that this cou= ld make overall performance worse: it will cause loaddefs.el to contain all= the signatures and docstrings of these helper functions, and loaddefs.el i= s itself not byte-compiled. Therefore, you now need to load the definitions= effectively twice: once in loaddefs.el, once the functions are actually us= ed. Therefore such a change shouldn't be made without measuring its imp= act.
I'd actually prefer going into the other direction: prel= oad much more than now, and remove lots of stuff from autoloads. This will = probably need a different strategy for preloading (Daniel's approach, o= r Rmacs, or an Elisp LLVM compiler, ...).
--f403045f57f01d4448054ca9c0e8--