From: Stefan Monnier <monnier@iro.umontreal.ca>
To: Alan Mackenzie <acm@muc.de>
Cc: Glenn Morris <rgm@gnu.org>, Chong Yidong <cyd@stupidchicken.com>,
emacs-devel@gnu.org
Subject: Re: Refactoring of emacs-lisp/autoload.el
Date: Wed, 13 Aug 2008 16:31:14 -0400 [thread overview]
Message-ID: <jwvbpzw8y6o.fsf-monnier+emacs@gnu.org> (raw)
In-Reply-To: <20080813141133.GC3010@muc.de> (Alan Mackenzie's message of "Wed, 13 Aug 2008 14:11:33 +0000")
>> No, this was not a bug. This section is present to speed up the refresh
>> of the loaddefs.el file, so that files that don't have other entries in
>> loaddefs.el don't have to be opened&scanned when they haven't changed
>> since the last time we refreshed loaddefs.el.
>> So calc/calc-aent.el should probably be mentioned in this list so as to
>> avoid having to open&scan it when it hasn't changed.
> OK. I haven't yet characterised fully the criterion for a file being in
> this list. I'm looking at that now.
Normally, all files should appear in loaddefs.el: either they have their
own section or they're in the "nothing to declare" section.
If there are a couple files not mentioned there, it's not tragic, tho.
The goal is that running "cd emacs/lisp; make autoloads" after
loaddefs.el has just been updated should only need to scan loaddefs.el,
and check the timestamp of all the .el files, and can then return
without reading any of the other (unchanged) elisp files, so that "make
autoloads" is almost immediate when it has nothing to do.
> Ah.. I hadn't properly understood the loop through the existing entries
> of loaddefs.el. This is surely to minimise the searching within
> loaddefs.el, which is very slow if it's done clumsily.
That loop was fairly inefficient.
> My strategy when inserting a new entry into loaddefs.el is to start
> searching from the current position in that file. So if the source files
> are processed in alphabetical order, the newer autoload.el should be just
> as fast (or, at least, fast enough).
Yes, that sounds fine.
>> The second case used to be unusably slow and I made it a lot faster
>> around Emacs-21 (or so), so now it's fast enough: please test it after
>> changing a handful of files, just to make sure that it's not
>> significantly slower than before.
> I'll test it. Could you suggest a typical test scenario, please? How
> many source files should I touch to test this? 3, 10, 30, 100?
Yes, 10, 30, 0, that sounds fine.
> I agree with all that. I've been taking as much care as possible.
Great.
> But I know nothing of its use by 3rd party packages. Do you know of
> any such uses, or is this a "there are probably some" situation?
I know I use it in sml-mode and haskell-mode and I know mh-e uses it as
well, but all three use it via batch-update-autoloads, so it should work
just fine. I just expect other uses since there are ;;;###autoload
cookies for other entry points. But indeed, I do not know of
concrete examples.
Stefan
next prev parent reply other threads:[~2008-08-13 20:31 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-08-12 16:23 Refactoring of emacs-lisp/autoload.el Alan Mackenzie
2008-08-12 20:09 ` Stefan Monnier
2008-08-12 20:58 ` Glenn Morris
2008-08-13 14:13 ` Alan Mackenzie
2008-08-13 16:11 ` Glenn Morris
2008-08-13 14:11 ` Alan Mackenzie
2008-08-13 20:31 ` Stefan Monnier [this message]
2008-08-14 13:17 ` Alan Mackenzie
2008-08-14 17:52 ` Stefan Monnier
2008-09-01 21:55 ` Alan Mackenzie
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
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=jwvbpzw8y6o.fsf-monnier+emacs@gnu.org \
--to=monnier@iro.umontreal.ca \
--cc=acm@muc.de \
--cc=cyd@stupidchicken.com \
--cc=emacs-devel@gnu.org \
--cc=rgm@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.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.