emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: bug#30854: 27.0.50; Speeding up package.el startup


From: arthur . miller
Subject: Re: bug#30854: 27.0.50; Speeding up package.el startup
Date: Fri, 18 Dec 2020 17:05:11 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux)

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>>> We could speed it up even further by byte-compiling this file, but this
>>> has bumped into some corner cases problems so I'm sticking to
>>> a non-compiled file for now.
>> Which corner cases apply to this? If it is OK to ask you?
>
> [ You quoted a lot of text, so I'm not completely sure, but `C-s` seemed
>   to indicate that you were referring to just those above three lines
>   I kept.  ]
Yes indeed, that was what I was mostly interested about.

> I can't remember off-hand.  Actually, I have a vague recollection that
> the problems turned out having some other origin.  So indeed we should
> byte-compile the resulting file.
That sounds great! Maybe more people could try it before you enable it
by default? It seems to work quite well for me, but people's setups
are so different.

>> compiling and baking package-quickstart.el into my init file (with
>> disabled package-quickstart).
>
> I don't know what this means.
Ah; sorry. That ment that I simply copy-pasted the content of
package-quickstart.el (minus some) into my init file, and compiled init file.

You can see here an excerpt as illustration:

( ...
      (when init-file-bake-autoloads
        (with-temp-buffer
          (when init-file-bake-autoloads
            (insert "(defvar package-activated-list nil)"))
          (insert-file-contents-literally "autoloads.el")
          (write-region (point-min) (point-max) "init.el" t 0)))
 ... )

(autoloads.el is just package-quickstart.el where I have prepended paths
and removed add-to-list lines)

>> I have also optimized it slightly: every autoload file adds it's own
>> path to load-path via add-to-list at startup time. But all those paths
>> are known when package-quickstart-refresh runs, so we can simply
>> concatenate them to one list and then emit code to just nconc emitted
>> that list to load-path at startup (this is what I do in my init file).
>
> I'm surprised a single call to `nconc` would be noticeably faster than
> a hundred calls to `add-to-list`.  I mean, obviously it's a lot faster,
> but unless you do that in a loop (which is not the case here),
> I wouldn't expect the difference to be measurable.

I don't know for sure what is going on here to be honest. Maybe it is
just result of byte-compilation alone, maybe there is more. I goofed a
little bit and didn't disabled 'quickstart' correctly when I was testing
this and I got same results with and without pre-calculated paths, so
you are probably correct there. The real speed boost came when I merged
content of package-quickstart.el with my init file and disabled
package-quickstart. It means package-initialize is not called so that
saves some time too I guess.

But byte compilation of that file gives boost in itself; just not as
much as I got when I disabled package-quickstart. So maybe could be
something for 28.0 if tested by more people?

Thanks for the answer.
/a



reply via email to

[Prev in Thread] Current Thread [Next in Thread]