Re: Loading a package applies automatically to future sessions?

[George Plymale II <georgedp@orbitalimpact.com>]

Hi all,

I'm the one who posted the question on Stack Exchange, which Stefan
mentioned the other day. My specific question is detailed here:
https://emacs.stackexchange.com/q/38368/10761

So, I've tried out Stefan's patch and it's definitely an improvement on
startup time, but the improvement is not huge for me. Specifically, I've
done the following in my startup files:

(setq package-enable-at-startup nil)
(load "~/.emacs.d/package-fastpath.el")
(setq package--initialized t)

I put that code in my files after running Stefan's
`package-fastpath-refresh'. I also set `load-source-file-function' to
nil as per Stefan's suggestion. Unfortunately, I couldn't byte-compile
my package-fastpath.el file due to some packages which already
byte-compile their autoload files, such as SLIME.

Now, I do see some improvement in my startup time, but to reiterate, it
is not huge. When I run Emacs with my startup commented out,
`emacs-init-time' yields 1.2 seconds. When I run it with my startup
intact, it yields 1.3 or 1.4 seconds. This contrasts with my previous
`emacs-init-time' which was 1.6 or 1.7 seconds, but as you can see, it's
not a really big difference.

It is possible that this sub-par time is due to something on my own
system, but I'm not sure nor convinced of that. Moreover, Stefan's patch
certainly can use some improvements and some notes on how to use his
changes, as it is a bit vexing to figure it out by reading the diff ;)

I did notice a few bugs with Stefan's changes. One bug was that
`package-installed-p' no longer yields correct results on installed
packages. I believe that this is because `package-desc-p' is also broken
by these changes. This broke some code in my startup which I used to
check whether I need to install new packages.

Another bug was that some packages were placed in bad order in
package-fastpath.el. In other words, if a dependency's autoloads are
written to this file after its dependent package, the dependent package
will err, saying that it couldn't require one of its dependencies. There
is obviously some work to do on making sure that dependencies are placed
in the correct order or to change the code so that package-fastpath.el
is order-agnostic.

As a side note and a bit of an opinion, Radon Rosborough made an
interesting remark in one of his messages. He mentioned pip and how
things are done in Python, which really struck me. You never really
think about using a package in a language like Python or Ruby. You just
`require' or `import' it and that's that. It's really simple and the
amount of packages that you have never hurts the startup of the main
program. I know that Emacs is a bit more complicated since it's more of
a text editor than a language and we have somewhat more intricacies to
worry about. But I think that this kind of a model is the kind we need
to be headed for.

A user should be able to have a million packages and not have to worry
about the subsequent startup time. Heck, in my own Ruby installation I
have 436 gems and I've never even thought about startup time till now.

In any case, I think Stefan's ideas and proposed changes are a good idea
and I am in much the same boat as John Wiegley in that I restart Emacs
often enough that startup time gets on my nerves. So I hope that we'll
have some real progress on this issue and make package.el more robust.

Thanks,
- George Plymale II