From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: Loading a package applies automatically to future sessions? Date: Thu, 01 Feb 2018 14:47:19 -0500 Message-ID: References: NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: blaine.gmane.org 1517514547 27183 195.159.176.226 (1 Feb 2018 19:49:07 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Thu, 1 Feb 2018 19:49:07 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) Cc: emacs-devel@gnu.org To: George Plymale II Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Feb 01 20:49:03 2018 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 1ehKqk-0005p1-EF for ged-emacs-devel@m.gmane.org; Thu, 01 Feb 2018 20:48:46 +0100 Original-Received: from localhost ([::1]:57953 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ehKsl-0001eX-CO for ged-emacs-devel@m.gmane.org; Thu, 01 Feb 2018 14:50:51 -0500 Original-Received: from eggs.gnu.org ([208.118.235.92]:53076) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ehKqR-0000yM-NV for emacs-devel@gnu.org; Thu, 01 Feb 2018 14:49:33 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ehKpN-0002Jb-Ii for emacs-devel@gnu.org; Thu, 01 Feb 2018 14:48:27 -0500 Original-Received: from chene.dit.umontreal.ca ([132.204.246.20]:47110) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ehKpN-0002JF-Ab for emacs-devel@gnu.org; Thu, 01 Feb 2018 14:47:21 -0500 Original-Received: from ceviche.home (lechon.iro.umontreal.ca [132.204.27.242]) by chene.dit.umontreal.ca (8.14.7/8.14.1) with ESMTP id w11JlJUj022076; Thu, 1 Feb 2018 14:47:20 -0500 Original-Received: by ceviche.home (Postfix, from userid 20848) id A4C9F66372; Thu, 1 Feb 2018 14:47:19 -0500 (EST) In-Reply-To: (George Plymale, II's message of "Wed, 31 Jan 2018 00:17:08 -0500") X-NAI-Spam-Flag: NO X-NAI-Spam-Threshold: 5 X-NAI-Spam-Score: 0 X-NAI-Spam-Rules: 2 Rules triggered EDT_SA_DN_PASS=0, RV6213=0 X-NAI-Spam-Version: 2.3.0.9418 : core <6213> : inlines <6357> : streams <1777745> : uri <2584527> X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 132.204.246.20 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:222367 Archived-At: > It looks like your code is fetching slime-autoloads.elc: > (let ((load-file-name "/Users/my_username/.emacs.d/elpa/slime-20180126.1033/slime-autoloads.elc")) > ;; ... bunches of bytecode > ) Hmm... good catch. I just added a corresponding FIXME in the code (hopefully M-x dwim will figure out how to fix it). >> Also, I'm not 100% surprised that byte-compiling byte-compiled code would >> fail, but I can't see any immediate reason why it should fail, so it's >> quite possible to it'd be easy to make it work. > Not sure why it would fail either, but this is the error that I see for > that specific chunk of bytecode: > package-fastpath.el:899:1:Error: Wrong type argument: sequencep, 1004 I'll see if I can reproduce it (it's probably better to try and use the .el file instead, tho). > And lo and behold, `emacs-init-time' yields 0.7 seconds. Which is just > 0.2 seconds higher than what I get with -Q, which I believe is Emacs' > peak startup time. I also verified that I have access to all my packages > so it is using package-fastpath.el. Good, thanks. Now the numbers correspond better to my expectations. > So that means your patch has actually increased startup time a lot more ^^^^^^^^^ improved > Well, actually those figures are better than what you're saying as per > my information above. I guess that makes your patch even more > respectable for a first stab! :) FWIW "a first stab" often ends up being faster than the end product, because the first stab was too optimistic. >> Hmm... I thought this can't happen because the files are concatenated in >> the same order that they are normally loaded by `package-initialize`. >> I guess something doesn't work the way I thought it does. >> Can you investigate to see when or even why it happens? > It specifically happened with gh.el (https://github.com/sigma/gh.el), > which is dependent on marshal.el (https://github.com/sigma/marshal.el) > > Apparently gh-autoloads.el uses a `gh-defclass' macro, which in turn > uses a `marshal-defclass' macro. There is definitely some strangeness > that could be going on here. Could you try and give some more details about this problem? E.g. check the fastpath file to see in which order the two packages's autoloads are placed. If gh-autoloads.el comes before marshal-autoloads.el, could you try and figure out why (e.g. maybe starting with `M-x trace-function RET package-activate RET` and `M-x trace-function RET package-activate-1 RET`)? Stefan