Re: Loading a package applies automatically to future sessions?

[T.V Raman]

George Plymale II <address@hidden> writes:

try let-binding file-name-handler-alist to nil -- in my case, that gave
a  significant speed-up  a few months ago > 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
>

--