interactive feel of Emacs: the need for speed, and -Q [measure.el]

interactive feel of Emacs: the need for speed, and -Q [measure.el]

[Emanuel Berg via Users list for the GNU Emacs text editor]

Elisp: Last in this post, for the impatient.

Question: Second last in this post, for the ... whatever.

Some time ago, I assembled a supposedly gamer computer.
This sounds cool but actually it was easy, anyone can do
it, it is just a matter of money. (This should be
contrasted to all other paths of life, which are 100%
altruistic. Errr)

Anyway before that, I had an RPi, which I used as
a general-purpose computer. I got used to the low speed
and didn't feel that was a problem.

Now when I'm in game mode, I do experience a significant
decrease in compile time and such tasks, and a noticable
speedup WRT the interactive feel of Emacs.

I have an Elisp program [last] which I ran with the RPi,
and now on this computer. Three functions are executed
10 000 times each, and then the execution times
are outputted.

The unit is "a float number of seconds since the epoch",
as `float-time' is used.

On the RPi, times were 0.08, 0.38, and 0.55. On the gamer
computer, the same tests are done in times 0.01, 0.01,
and 0.05. (Maybe 0.01 indicates "too fast to measure"?)
So if I've done the math correctly, comparing the two
computers, the gamer computer has at least an 88%, 97%,
and 91% edge!

Still, when I invoke Emacs with -Q, the interactive feel
is much faster. This was true on the RPi as well, and the
relative difference was felt to be roughly the same.

The explanation given when this has been discussed is
that a lot of configuration/extension imposes hooks that
slow down the interactive feel. However I can't say
a rely a lot on hooks. When I do, they are one line of
Elisp to toggle `line-number-mode', and such. I _do_ have
a lot of Elisp (some 7 000 lines), *but* what I can see it
is for the most part just chunks of code that are not
used on an everyday basis. I have as much zsh shell
functions and they certainly do not slow zsh down by just
being there!

So I wonder, what exactly is brought in _without_ -Q that
slow Emacs down, and in particular the interactive feel?

Thanks for reading :)

;;; -*- lexical-binding: t -*-
;;;
;;; this file: http://user.it.uu.se/~embe8573/emacs-init/measure.el
;;;            https://dataswamp.org/~incal/emacs-init/measure.el

(require 'cl-lib)

(defun point-at-final-line-1 ()
  (= (line-number-at-pos)
     (line-number-at-pos (point-max)) ))

(defun point-at-final-line-2 ()
  (save-excursion
    (end-of-line)
    (= 1 (forward-line) )))

(defun point-at-final-line-3 ()
  (= (line-end-position) (point-max)) )

(defmacro measure-time (&rest body)
  "Measure and return the running time of the code block.
Thanks: http://nullprogram.com/blog/2009/05/28/"
  (declare (indent defun))
  (let ((start (make-symbol "start")))
    `(let ((,start (float-time)))
       ,@body
       (- (float-time) ,start) )))

(defun create-random-list (max len)
  (let ((l '()))
    (cl-loop repeat len do
      (push (random max) l))
    l) )

(defun test-final-line-f (fun pos-list)
  (cl-loop for p in pos-list do
    (goto-char p)
    (apply fun nil) ))

(defun test-final-line (its)
  (let*((max      (point-max))
        (pos-list (create-random-list max its))
        (funs     (list #'point-at-final-line-1
                        #'point-at-final-line-2
                        #'point-at-final-line-3) )
        (times    '()) )
    (cl-loop for f in funs do
      (push (list f (measure-time (test-final-line-f f pos-list))) times) )
    (goto-char (point-max))
    (let ((sorted-times (cl-sort times #'< :key #'cadr)))
      (cl-loop for time in sorted-times do
        (insert (format "\n;; %s  %0.2f" (car time) (cadr time))) ))))

;; (test-final-line 10000)
;;                        ^eval me
;; results on RPi3:
;;
;;   point-at-final-line-3  0.08
;;   point-at-final-line-2  0.38
;;   point-at-final-line-1  0.55
;;
;; gamer computer:
;;
;;   point-at-final-line-3  0.01
;;   point-at-final-line-2  0.01
;;   point-at-final-line-1  0.05
;;
;; improvements:
;;
;;   (format "%.0f%%" (- 100 (* 100 (/ 0.01 0.08)))) ; 88%
;;   (format "%.0f%%" (- 100 (* 100 (/ 0.01 0.38)))) ; 97%
;;   (format "%.0f%%" (- 100 (* 100 (/ 0.05 0.55)))) ; 91%

-- 
underground experts united
http://user.it.uu.se/~embe8573
https://dataswamp.org/~incal

RE: interactive feel of Emacs: the need for speed, and -Q [measure.el]

[Drew Adams]

Not sure what you're asking.  But if you're asking
which parts of your non -Q setup could be causing
a slowdown then the answer is typically to bisect
your init file, to narrow the search.

There's also profiling, which you can do after
you've narrowed things down to specific code, if
things aren't obvious at that point.

But I think you already knew this, so probably
I've misunderstood the question.

Re: interactive feel of Emacs: the need for speed, and -Q [measure.el]

[Emanuel Berg via Emacs development discussions.]

Drew Adams wrote:

> Not sure what you're asking.  But if you're asking
> which parts of your non -Q setup could be causing
> a slowdown then the answer is typically to bisect
> your init file, to narrow the search.

Why would a bunch of defuns that are not called slow
down the interactive feel w/o even being invoked?

Like I said, I think I have as much zsh [1] that I have
Elisp [2] but it sure doesn't slow down zsh in general.
It is mostly the same stuff, just functions that do
stuff. They aren't invoked unless they user says so.
But I don't have to do _anything_ to instantly feel that
-Q is much, much faster. Just typing and doing M-x!

What in general slows it down? Or does a defun, that
isn't called, slow it down by just being there, in
Emacs? If so, why?

If it doesn't, what stuff should you look out for?

Hooks I accept slow things down, if they are called all
the time and you put elaborate things in them, but
I don't think they are and I don't. advice I used
literally once in 100+ files.

What else is slowing things down in general
I don't know.

So "non -Q" only does that and only that, brings in the
user's init stuff? Nothing else that the user is unaware
of and do not control with/from his/her init file(s)?


[1] https://dataswamp.org/~incal/conf/.zsh/

[2] https://dataswamp.org/~incal/emacs-init/

-- 
underground experts united
http://user.it.uu.se/~embe8573
https://dataswamp.org/~incal

Re: interactive feel of Emacs: the need for speed, and -Q [measure.el]

[Michael Welsh Duggan]

Emanuel Berg via "Emacs development discussions." <emacs-devel@gnu.org>
writes:

> Why would a bunch of defuns that are not called slow
> down the interactive feel w/o even being invoked?
>
> Like I said, I think I have as much zsh [1] that I have
> Elisp [2] but it sure doesn't slow down zsh in general.
> It is mostly the same stuff, just functions that do
> stuff. They aren't invoked unless they user says so.
> But I don't have to do _anything_ to instantly feel that
> -Q is much, much faster. Just typing and doing M-x!
>
> What in general slows it down? Or does a defun, that
> isn't called, slow it down by just being there, in
> Emacs? If so, why?
>
> Hooks I accept slow things down, if they are called all
> the time and you put elaborate things in them, but
> I don't think they are and I don't. advice I used
> literally once in 100+ files.
>
> [1] https://dataswamp.org/~incal/conf/.zsh/

It's hard to tell from your posted list of elisp files, as I don't
really want to download and check them all.  You'll want to check
anything that you `require` that isn't something you wrote, as loading
any elisp can add hooks, etc.

> So "non -Q" only does that and only that, brings in the
> user's init stuff? Nothing else that the user is unaware
> of and do not control with/from his/her init file(s)?

Emacs invoked without -Q also can load in a default init file and a site
file.  (See emacs info: "The Emacs Initialization File".)  You can turn
off the latter using --no-site-file (which is implied by -Q), and you
can turn off the former by adding (setq inhibit-default-init t) in your
init file.

-- 
Michael Welsh Duggan
(md5i@md5i.com)

Re: interactive feel of Emacs: the need for speed, and -Q [measure.el]

[Emanuel Berg via Emacs development discussions.]

Michael Welsh Duggan wrote:

> off the latter using --no-site-file

Thanks, that works with all my Elisp!

Perhaps it isn't that big? Where is it? The man page for
emacs(1) just says what it do (or don't), "Do not load
the site-wide startup file." - OS/distro specific
location/contents?

Or is my Elisp just plain modular? :)

> (See emacs info: "The Emacs Initialization File".)

(info "(emacs) Init File") ?

Seems to by default be, uhm, default.el and
site-start.el, in /usr/local/share/emacs/site-lisp ...
only that is empty for me... ?

> (which is implied by -Q), and you can turn off the
> former by adding (setq inhibit-default-init t) in your
> init file

Again, that didn't brake anything.

OK, so I greped the drive for default.el and
site-start.el, either my commands stink or they don't
exist on the drive.

Most likely, they are not the reason!

But do I `require' tons of stuff as you mention as
a possible cause. but shouldn't that be sound stuff that
don't overpopulate hooks etc? actually, I have 273
`require's! But as long as that's sound stuff,
where/what is the problem? sum effect?

Most of it is just vanilla Emacs stuff being required so
configuration and extension will go thru compilation w/o
error messages a/o warnings, I'm not a heavy M/ELPA user
at all, not that I think quality anywhere should be so
lousy it'd cause all this...

Thank you...

-- 
underground experts united
http://user.it.uu.se/~embe8573
https://dataswamp.org/~incal

Re: interactive feel of Emacs: the need for speed, and -Q [measure.el]

[Michael Welsh Duggan]

Emanuel Berg via "Emacs development discussions." <emacs-devel@gnu.org>
writes:

> Michael Welsh Duggan wrote:
>
>> off the latter using --no-site-file
>
> Thanks, that works with all my Elisp!
>
> Perhaps it isn't that big? Where is it? The man page for
> emacs(1) just says what it do (or don't), "Do not load
> the site-wide startup file." - OS/distro specific
> location/contents?
>
> Or is my Elisp just plain modular? :)
>
>> (See emacs info: "The Emacs Initialization File".)
>
> (info "(emacs) Init File") ?

Sorry, yes.  A slightly more detailed explanation can be found in (info
"(elisp) Startup Summary").

> Seems to by default be, uhm, default.el and
> site-start.el, in /usr/local/share/emacs/site-lisp ...
> only that is empty for me... ?

Could be anywhere in the load-path.  

>> (which is implied by -Q), and you can turn off the
>> former by adding (setq inhibit-default-init t) in your
>> init file
>
> Again, that didn't brake anything.
>
> OK, so I greped the drive for default.el and
> site-start.el, either my commands stink or they don't
> exist on the drive.
>
> Most likely, they are not the reason!
>
> But do I `require' tons of stuff as you mention as
> a possible cause. but shouldn't that be sound stuff that
> don't overpopulate hooks etc? actually, I have 273
> `require's! But as long as that's sound stuff,
> where/what is the problem? sum effect?

It's too hard to say for sure.  Some packages have more of an effect
than others.  That is why it is recommended to bisect your emacs init
file to find out what might be causing the problem.

Although you showed a list of your customizations split between files, I
have no idea how you are loading these files, whether it is due to a
list of require statements in your init file or if you do something
else.  If the list of things you set/load/include is fairly small at the
top-level, it might be worth starting with -Q and then manually
evaluating your init file with C-x C-e until you find out what is
causing you problems.  

> Most of it is just vanilla Emacs stuff being required so
> configuration and extension will go thru compilation w/o
> error messages a/o warnings, I'm not a heavy M/ELPA user
> at all, not that I think quality anywhere should be so
> lousy it'd cause all this...

Once again, I couldn't say.  Although the code quality of the elisp
distributed with Emacs is fairly high, it is a large community project,
and not everything is tested equally.  Some packages are used by only a
small number of people, while others are used by just about everybody.
And different people have differing expectations when it comes to
interactivity (and different computers which may be slower/faster).  One
thing I can say for certain is that the current set of active
maintainers has done a very good job of tracking the bug reporting list
and working hard at alleviating defects, once they are reported.

-- 
Michael Welsh Duggan
(md5i@md5i.com)

Re: interactive feel of Emacs: the need for speed, and -Q [measure.el]

[Emanuel Berg via Emacs development discussions.]

Michael Welsh Duggan wrote:

> Once again, I couldn't say. Although the code quality
> of the elisp distributed with Emacs is fairly high, it
> is a large community project, and not everything is
> tested equally. Some packages are used by only a small
> number of people, while others are used by just about
> everybody. And different people have differing
> expectations when it comes to interactivity (and
> different computers which may be slower/faster).
> One thing I can say for certain is that the current
> set of active maintainers has done a very good job of
> tracking the bug reporting list and working hard at
> alleviating defects, once they are reported.

OK, thank, are there any general rules that makes sense?

- defuns that are loaded but not invoked do not slow
  Emacs down, as before and after execution, they are
  just a bunch of text

- hooks, advice, and scheduled stuff (with the idle
  timer) might slow things down, but shouldn't unless
  the stuff one puts there is expensive

- huge software systems that runs all the time and/or
  spawns their own processes (e.g., Gnus, ERC) could
  slow things down, but again, why would that be
  a problem unless the payload in particular is very
  expensive somewhere?

- it is likely that what slows down Emacs in general is
  ... ?

Re: binary search of the init file, this implies that
there is some specific one or two problem areas or
"villains", but I'm not sure there is. The reason
I think so is that -Q Emacs is, and has always been,
much faster _in general_, not in a specific situation.

Here are my requires:

(require 'ada-mode)
(require 'apropos)
(require 'bibtex)
(require 'cc-mode)
(require 'checkdoc)
(require 'cl-lib)
(require 'comint)
(require 'compile)
(require 'css-mode)
(require 'debug)
(require 'dired)
(require 'dired-x)
(require 'erc)
(require 'erc-button)
(require 'erc-fill)
(require 'erc-match)
(require 'erc-ring)
(require 'erc-stamp)
(require 'gnus)
(require 'gnus-art)
(require 'gnus-cite)
(require 'gnus-group)
(require 'gnus-msg)
(require 'gnus-score)
(require 'gnus-srvr)
(require 'gnus-start)
(require 'gnus-sum)
(require 'google-translate-core-ui)
(require 'help-mode)
(require 'ielm)
(require 'info)
(require 'ispell)
(require 'lpr)
(require 'man)
(require 'map)
(require 'message)
(require 'netrc)
(require 'nnmail)
(require 'nroff-mode)
(require 'package)
(require 'parse-time)
(require 'search-regexp-in-files)
(require 'seq)
(require 'sgml-mode)
(require 'shell)
(require 'slime)
(require 'slime-autoloads)
(require 'slime-presentations)
(require 'slime-repl)
(require 'smtpmail)
(require 'sort)
(require 'subr-x)
(require 'tex-mode)
(require 'thingatpt)
(require 'tls)
(require 'tramp)
(require 'w3m)
(require 'w3m-bookmark)
(require 'w3m-form)
(require 'w3m-search)
(require 'w3m-session)

-- 
underground experts united
http://user.it.uu.se/~embe8573
https://dataswamp.org/~incal

Re: interactive feel of Emacs: the need for speed, and -Q [measure.el]

[Michael Welsh Duggan]

I'm not prepared to respond in detail right now, but I will ask a couple
of questions that pop into my head right now.  First, is the slow-down
you notice in all buffers, or specifically in buffers in specific modes
(like c-mode)?  If the latter, what is the value of
`after-change-functions' in those buffers?  Although this hook isn't the
only possible place that can cause slow downs, it is a hook that can be
called very often, and if too much is run in it, that can slow things
down.

Another thing that can slow things down is excessive garbage
collection.  Try setting `garbage-collection-messages' to non-nil.  This
will cause messages to be output when Emacs does a GC run.  Run it with
and without -Q and see if there is a significant difference in the
frequency.  Possibly tweak `gc-cons-threshold' and see if it makes a
difference.

Others may be able to suggest more, but this is the best I can suggest
while fighting off a (literal) headache.

-- 
Michael Welsh Duggan
(md5i@md5i.com)

Re: interactive feel of Emacs: the need for speed, and -Q [measure.el]

[Emanuel Berg via Emacs development discussions.]

Michael Welsh Duggan wrote:

> I'm not prepared to respond in detail right now, but
> I will ask a couple of questions that pop into my head
> [...]

Maybe it is my imagination but I do think this made
it faster. Not the first option, but I include
it anyway.

(setq inhibit-default-init t)
(setq garbage-collection-messages t)
(setq gc-cons-threshold 2000000)

> `after-change-functions' [...]

This seems to be (jit-lock-after-change t) in most
edit modes.

> headache [...]

I'm sorry to hear that :( Stretching works for me...

-- 
underground experts united
http://user.it.uu.se/~embe8573
https://dataswamp.org/~incal

Re: interactive feel of Emacs: the need for speed, and -Q [measure.el]

[T.V Raman]

See this blog article I wrote on how I sped up startup of Emacs for
myself.

https://emacspeak.blogspot.com/2017/08/emacs-start-up-speeding-it-up.html
-- 

Re: interactive feel of Emacs: the need for speed, and -Q [measure.el]

[Emanuel Berg via Emacs development discussions.]

T.V Raman wrote:

> See this blog article I wrote on how I sped up startup
> of Emacs for myself.
>
> https://emacspeak.blogspot.com/2017/08/emacs-start-up-speeding-it-up.html

OK, cool, but does it apply to the interactive speed
as well?

If so, what parts?

IME startup time isn't an issue since 1) it's fast, and
2) I don't do it often.

-- 
underground experts united
http://user.it.uu.se/~embe8573
https://dataswamp.org/~incal

Re: interactive feel of Emacs: the need for speed, and -Q [measure.el]

[T.V Raman]

0 impact on interaction 
-- 

Re: interactive feel of Emacs: the need for speed, and -Q [measure.el]

[Basil L. Contovounesios]

Emanuel Berg via "Emacs development discussions." <emacs-devel@gnu.org>
writes:

> Here are my requires:
>
> (require 'ada-mode)
> (require 'apropos)
> (require 'bibtex)
> (require 'cc-mode)
> (require 'checkdoc)
> (require 'cl-lib)
> (require 'comint)
> (require 'compile)
> (require 'css-mode)
> (require 'debug)
> (require 'dired)
> (require 'dired-x)
> (require 'erc)
> (require 'erc-button)
> (require 'erc-fill)
> (require 'erc-match)
> (require 'erc-ring)
> (require 'erc-stamp)
> (require 'gnus)
> (require 'gnus-art)
> (require 'gnus-cite)
> (require 'gnus-group)
> (require 'gnus-msg)
> (require 'gnus-score)
> (require 'gnus-srvr)
> (require 'gnus-start)
> (require 'gnus-sum)
> (require 'google-translate-core-ui)
> (require 'help-mode)
> (require 'ielm)
> (require 'info)
> (require 'ispell)
> (require 'lpr)
> (require 'man)
> (require 'map)
> (require 'message)
> (require 'netrc)
> (require 'nnmail)
> (require 'nroff-mode)
> (require 'package)
> (require 'parse-time)
> (require 'search-regexp-in-files)
> (require 'seq)
> (require 'sgml-mode)
> (require 'shell)
> (require 'slime)
> (require 'slime-autoloads)
> (require 'slime-presentations)
> (require 'slime-repl)
> (require 'smtpmail)
> (require 'sort)
> (require 'subr-x)
> (require 'tex-mode)
> (require 'thingatpt)
> (require 'tls)
> (require 'tramp)
> (require 'w3m)
> (require 'w3m-bookmark)
> (require 'w3m-form)
> (require 'w3m-search)
> (require 'w3m-session)

FWIW eagerly loading such a non-trivial amount of large packages is very
likely to be slow, even if each one comprises only top-level
definitions.  Simply loading Gnus alone can take upwards of 500ms on my
machine.  Occasionally less well-behaved packages execute non-trivial
code at top-level, thus incurring a further cost when loading them.

For faster initialisation, try to avoid loading packages until they are
needed.  A couple of features that can help with this are autoloading[1]
and with-eval-after-load[2].

[1]: (info "(elisp) Autoload")
[2]: (info "(elisp) Hooks for Loading")

-- 
Basil

Re: interactive feel of Emacs: the need for speed, and -Q [measure.el]

[Stefan Monnier]

>> Here are my requires:

As a general rule, `require` should not appear in a `~/.emacs`.
It's for use at the top of a library file.


        Stefan

Re: interactive feel of Emacs: the need for speed, and -Q [measure.el]

[Stephen Leake]

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

>>> Here are my requires:
>
> As a general rule, `require` should not appear in a `~/.emacs`.
> It's for use at the top of a library file.

They should be replaced with the relevant (load-file "...autoloads").

And ada-mode in particular is in ELPA, so it is handled by
package-initialize; others may be packages as well.

-- 
-- Stephe

Re: interactive feel of Emacs: the need for speed, and -Q [measure.el]

[Clément Pit-Claudel]

On 16/04/2020 15.14, Stephen Leake wrote:
> Stefan Monnier <monnier@iro.umontreal.ca> writes:
> 
>>>> Here are my requires:
>>
>> As a general rule, `require` should not appear in a `~/.emacs`.
>> It's for use at the top of a library file.

What's the replacement, then?

> They should be replaced with the relevant (load-file "...autoloads").

That doesn't do the same thing at all.  What if you want to use functions that are not autoloaded, or macros?

Re: interactive feel of Emacs: the need for speed, and -Q [measure.el]

[Stefan Monnier]

> They should be replaced with the relevant (load-file "...autoloads").

Indeed, tho this part should happen automatically thanks to your
package manager (except for non-standard situations).


        Stefan

Re: interactive feel of Emacs: the need for speed, and -Q [measure.el]

[Stefan Monnier]

>>>>> Here are my requires:
>>> As a general rule, `require` should not appear in a `~/.emacs`.
>>> It's for use at the top of a library file.
> What's the replacement, then?
>> They should be replaced with the relevant (load-file "...autoloads").
> That doesn't do the same thing at all.  What if you want to use functions
> that are not autoloaded, or macros?

In your ~/.emacs?

Presumably if users can be expected to use a function/macro directly
from ~/.emacs, the package should mark that function/macro as autoloaded
(especially for macros; for functions this can often be avoided if the
function is expected to be called only from with the corresponding mode
hook or an `eval-after-load`).

If not, it's a case that doesn't fall within the "general rule" and then
you'd have to consider the details to know what *should* happen and what
can be done temporarily until the ideal situation can be applied.


        Stefan

Re: interactive feel of Emacs: the need for speed, and -Q [measure.el]

[Stephen Leake]

Clément Pit-Claudel <cpitclaudel@gmail.com> writes:

> On 16/04/2020 15.14, Stephen Leake wrote:
>> Stefan Monnier <monnier@iro.umontreal.ca> writes:
>> 
>>>>> Here are my requires:
>>>
>>> As a general rule, `require` should not appear in a `~/.emacs`.
>>> It's for use at the top of a library file.
>
> What's the replacement, then?
>
>> They should be replaced with the relevant (load-file "...autoloads").
>
> That doesn't do the same thing at all. What if you want to use
> functions that are not autoloaded, or macros?

Speaking as the ada-mode author, if you have a use case for an ada-mode
function that should work this way but does not currently, please report
it as a bug (either in debbugs or on the ada-mode mailing list).

Other packages should also treat such use cases as bugs.

On the other hand, if you are using non-autoloaded functions from some
package in your own code, then your code should be in a file with the
necessary "requires" at the top.

-- 
-- Stephe

Re: interactive feel of Emacs: the need for speed, and -Q [measure.el]

[chad]

[-- Attachment #1: Type: text/plain, Size: 1373 bytes --]

I long ago adopted the use of require in my .emacs file as a well-worn
shorthand for "load this unless it's already loaded". Is there an
alternative that I should be using instead? (Please forgive the thread
necromancy; I just ran across this usage of require again today, and
remembered this thread.)

Thanks,
~Chad

On Thu, Apr 16, 2020 at 1:14 PM Stefan Monnier <monnier@iro.umontreal.ca>
wrote:

> >>>>> Here are my requires:
> >>> As a general rule, `require` should not appear in a `~/.emacs`.
> >>> It's for use at the top of a library file.
> > What's the replacement, then?
> >> They should be replaced with the relevant (load-file "...autoloads").
> > That doesn't do the same thing at all.  What if you want to use functions
> > that are not autoloaded, or macros?
>
> In your ~/.emacs?
>
> Presumably if users can be expected to use a function/macro directly
> from ~/.emacs, the package should mark that function/macro as autoloaded
> (especially for macros; for functions this can often be avoided if the
> function is expected to be called only from with the corresponding mode
> hook or an `eval-after-load`).
>
> If not, it's a case that doesn't fall within the "general rule" and then
> you'd have to consider the details to know what *should* happen and what
> can be done temporarily until the ideal situation can be applied.
>
>
>         Stefan
>
>
>

[-- Attachment #2: Type: text/html, Size: 1879 bytes --]

Re: interactive feel of Emacs: the need for speed, and -Q [measure.el]

[Stephen Leake]

chad <yandros@gmail.com> writes:

> I long ago adopted the use of require in my .emacs file as a well-worn
> shorthand for "load this unless it's already loaded". Is there an
> alternative that I should be using instead? 

If the file you are requiring has autoloads, then those autoloads should
be in some *autoloads.el file; load that instead.


-- 
-- Stephe

Re: interactive feel of Emacs: the need for speed, and -Q [measure.el]

[Stefan Monnier]

> I long ago adopted the use of require in my .emacs file as a well-worn
> shorthand for "load this unless it's already loaded". Is there an
> alternative that I should be using instead?

If what you want is "load this unless it's already loaded", then
`require` is the answer.  But the code in ~/.emacs should not about
about "loading" it should be about enabling/disabling: loading a file
(other than the init file, that is) should never noticeably affect
Emacs's behavior, so "loading" should be of no concern when writing your
config file (unless you're concerned about pre-loading a package for
performance reasons, maybe).


        Stefan

Re: interactive feel of Emacs: the need for speed, and -Q [measure.el]

[chad]

[-- Attachment #1: Type: text/plain, Size: 1381 bytes --]

I'm loading code that I wrote, because I don't maintain my emacs
configuration as a single big pile of elisp used on every system (I grew up
in a very heterogenous environment at MIT). The code is safe to load
multiple times; I avoid doing so to avoid the overhead, and because in a
more complicated past there were include-loops to avoid. At some point in
the middle, I built myself a pair of functions enable-quiet/disable-quiet
to handle this sort of thing; it sounds like maybe I should dust that off
again. FWIW, I wonder if anyone here would recommend building it around
load-file or require, and why.

Thanks!
~Chad

On Thu, Apr 23, 2020 at 1:57 PM Stefan Monnier <monnier@iro.umontreal.ca>
wrote:

> > I long ago adopted the use of require in my .emacs file as a well-worn
> > shorthand for "load this unless it's already loaded". Is there an
> > alternative that I should be using instead?
>
> If what you want is "load this unless it's already loaded", then
> `require` is the answer.  But the code in ~/.emacs should not about
> about "loading" it should be about enabling/disabling: loading a file
> (other than the init file, that is) should never noticeably affect
> Emacs's behavior, so "loading" should be of no concern when writing your
> config file (unless you're concerned about pre-loading a package for
> performance reasons, maybe).
>
>
>         Stefan
>
>

[-- Attachment #2: Type: text/html, Size: 1826 bytes --]

Re: interactive feel of Emacs: the need for speed, and -Q [measure.el]

[Stefan Monnier]

> I'm loading code that I wrote, because I don't maintain my emacs
> configuration as a single big pile of elisp used on every system (I
> grew up in a very heterogenous environment at MIT).

This seems to fall outside the scope of the general rule.
It may make perfect sense to use `require` in such a case.


        Stefan