From: Bob Proulx <bob@proulx.com>
To: help-gnu-emacs@gnu.org
Subject: Re: Interesting problem: eval-after-load and local variables
Date: Thu, 18 Oct 2012 11:46:49 -0600 [thread overview]
Message-ID: <20121018174648.GA9082@hysteria.proulx.com> (raw)
In-Reply-To: <k5ou7l$705$1@ger.gmane.org>
Kevin Rodgers wrote:
> Sebastien Vauban wrote:
> > I know. And this is a very somewhat ridiculous example. But, for
> > speed and clarity of my .emacs, I've generally put all customs
> > inside an eval-after-load. A setq is certainly not time-taker,
> > certainly not when alone, but I've applied the same principal to
> > many other blocks of customs.
>
> I don't see how the eval-after-load boilerplate provides any speed
> or clarity.
I don't know about clarity, although it is nice to know where things
are used, but it can save a very large amount of time when you are
loading up a lot of various bits of emacs functionality. Things start
up fairly quickly when doing nothing.
$ time emacs -Q -f kill-emacs
real 0m0.820s
user 0m0.088s
sys 0m0.040s
But on a system where I have many things being loaded with require
this and require that and all of those are required to be loaded
before I have a working emacs and can see and type in anything:
$ time emacs -f kill-emacs
real 0m8.362s
user 0m0.580s
sys 0m0.168s
That is a *HUGE* difference. By making use of eval-after-load I have
reduced that startup time to this. It isn't on the same system and
not directly comparable to the above so I will show both times for
comparison. And it is on these slower systems where the full load
times were very long and motivated me to optimize the startup.
$ time emacs -Q -f kill-emacs
real 0m1.940s
user 0m0.156s
sys 0m0.060s
$ time emacs -f kill-emacs
real 0m2.423s
user 0m0.260s
sys 0m0.132s
And I still have a ways to go. (Just noting that in the above I
dropped caches between runs making those cold disk accesses for all.)
It was more than 2x slower and the original startup time of the fully
loaded emacs with lots of requires was around 18 seconds. Getting
that down to less than 2.5 seconds was a huge win. Now I need to go
back and hit my original machine and get that 8 second load time now.
Using eval-after-load and lazy-loading libraries on demand as they are
needed can be a huge startup speed improvement over simply requiring
libraries and loading every possible thing at every startup. You
probably aren't going to ise it. And if you do then you can load it
then.
Bob
next prev parent reply other threads:[~2012-10-18 17:46 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-10-16 8:02 Interesting problem: eval-after-load and local variables Sebastien Vauban
2012-10-16 9:18 ` Peter Dyballa
2012-10-16 17:54 ` Michael Heerdegen
2012-10-17 3:23 ` Kevin Rodgers
[not found] ` <mailman.11151.1350444234.855.help-gnu-emacs@gnu.org>
2012-10-17 8:32 ` Sebastien Vauban
2012-10-18 4:09 ` Michael Heerdegen
2012-10-18 12:55 ` Kevin Rodgers
2012-10-18 17:46 ` Bob Proulx [this message]
[not found] ` <mailman.11221.1350564945.855.help-gnu-emacs@gnu.org>
2012-10-19 9:40 ` Sebastien Vauban
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20121018174648.GA9082@hysteria.proulx.com \
--to=bob@proulx.com \
--cc=help-gnu-emacs@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).